That won't work for intl/ICU: 1. It doesn't require number of items to get translation string for plurals. 2. Selecting sub-string for plurals happens at the same stage as formatting a message. These cannot be separated.
On Monday, April 1, 2019 at 8:12:37 PM UTC+3, Oscar Otero wrote: > > Hi, Alexander. > Thanks for your availability to work on this. I don’t have much time > currently but can help as a part of the working group if finally this psr > goes forward. > > About your comments: > > - 1 & 2. You’re right. The message argument is the ID of the message. > Sometimes it can be used as fallback text (like in gettext), but it’s out > of the spec. In fact, the spec says it must return NULL if no translation > was found. > - 3, 5. Yes, plural support is very important. I’m the maintainer of > https://github.com/oscarotero/Gettext that can handle plurals of any > language. Anyway, for implementations not supporting plurals, we can divide > the spec in two different interfaces or throw an exception. > - 4. The parameters are not part of the spec for various reasons: > - You’re mixing placeholder parameters with the counter argument used > for plurals. They are different things and the counter argument should be > typed. > - This force us to define a placeholder format that will be incompatible > with most existing i18n implementations. ({user}, :user, %user%, etc…) > - There’s no need to concatenate messages. You can use sprintf, strtr, > or any other method to search/replace placeholders for final values. And I > think this should be out of the scope of this spec. For example, is better > sprintf($foobar->translate(‘Hello, %s), $user) than > $foobar->translate(‘Hello %s’, [‘user’]). By dividing the translation and > placeholders in two different functionalities, we have a more flexible spec. > - We may need to transform these parameters to fit with the current > locale settings (decimal separators for numbers, date formats, etc). In > fact, after my initial proposal, there was some discussions to include the > FormatterInterface (or something like this) in order to combine both worlds > (for example gettext and Intl extension). Sorry, this conversation was lost > because it was in a slack channel from long time ago and old messages are > removed due limit free plan. > > > > > > > > > El 1 abr 2019, a las 13:40, 'Alexander Makarov' via PHP Framework > Interoperability Group <[email protected] <javascript:>> escribió: > > Yes, the tool is necessary as well as fallbacks mechanics. We have all > that in Yii and I can not imagine working with translations without these > extra tools. Extracting translations is not that complex btw. I don't think > that sticking to gettext is a good idea. ICU/intl is far superior in > flexibility. > > On Monday, April 1, 2019 at 7:52:23 AM UTC+3, Mikko Rantalainen wrote: >> >> On Saturday, 30 March 2019 22:33:44 UTC+2, [email protected] wrote: >>> >>> This is kind of what I am thinking. >>> >>> $error = "What the hell are you doing? Read the fine manual. Everyone >>> knows that you can not overwrite /etc/shadow from a web application."; >>> $foobar = new classThatImplements('\Psr\Localization\Translation'); >>> $error = $foobar->translateString($error, $bcp47); >>> >>> It would potentially allow applications to load their own translations >>> into such a class w/o needing to implement the backend themselves and then >>> retrieve them as needed, possibly even a class that is good at compensating >>> for translations the web application does not have translations for, >>> written by programmers who understand localization and create >>> implementations of the interface. >>> >> >> I find this kind of interface problematic in practice. One major issue >> that especially translations have is that there needs to be a tool that can >> extract *all* strings that need to be translated and as I see it, you >> either have something like gettext where tools extract the strings from the >> source code or the programmers need to manually collect all strings into >> some file and refer those strings using some kind of IDs in the source code. >> >> I've used both variants in the history and I feel that the gettext style >> is far easier for the programmers. Both are about equally hard for the >> translators. >> >> The variant you suggest above needs a tool that can statically extract >> all strings by evaluating the source code which would require quite complex >> tool. >> >> The only thing currently missing from the gettext support is ability to >> override the "_" method which is currently hardwired to gettext(). If We >> had ability to map function "_" to some custom class and in addition have >> "__" mapped to ngettext and "___" mapped to dcngettext by default but still >> mappable to something else, I guess we would have a winner. >> >> As for the localization names and float/monetary formatting, those should >> have more similar interface. Currently every part currently needs different >> interface. >> >> TimeZone support is pretty good already. Olson database just needs more >> information. >> >> -- >> Mikko >> >> > -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/cf274691-629f-402a-b6ff-9d2adf9e570c%40googlegroups.com > > <https://groups.google.com/d/msgid/php-fig/cf274691-629f-402a-b6ff-9d2adf9e570c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/4925e8d1-f6a9-405a-9efb-2aa4c30dae04%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
