Great that we agree. About Android XML, I’d rather return always strings, so a workaround could be specify the array index in the id. For example $translator->translate(‘minutes_count[0]’) or something similar, depending of the implementation. We'll see.
> How about moving > https://gist.github.com/oscarotero/33e3af8741045c2a1a5a89310571cbdb > <https://gist.github.com/oscarotero/33e3af8741045c2a1a5a89310571cbdb> to WG > github repository? I'm interested in proposing changes and putting together a > strong meta. That would great. Feel free to copy the gist to a new github repository and work on changes. But, AFAIK, the policy of fig is work in repositories in the php-fig organization. > El 4 abr 2019, a las 1:17, 'Alexander Makarov' via PHP Framework > Interoperability Group <[email protected]> escribió: > > How about moving > https://gist.github.com/oscarotero/33e3af8741045c2a1a5a89310571cbdb > <https://gist.github.com/oscarotero/33e3af8741045c2a1a5a89310571cbdb> to WG > github repository? I'm interested in proposing changes and putting together a > strong meta. > > On Thursday, April 4, 2019 at 2:12:55 AM UTC+3, Alexander Makarov wrote: > I've made some more research on common and not so common formats. > There's a good overview at https://docs.transifex.com/formats/introduction > <https://docs.transifex.com/formats/introduction> and you're right that > between all these formats there two main variations: > > 1. The ones that rely on formatting for plurals and many other things. > 2. The ones that have special handling for plurals at message format level. > > There are no other parameter-based variations. So now I agree that both > methods are part of the interface. > > Another thing that is in more than a single format has is support for arrays > of strings i.e. you may obtain an array by message id, not a string (see > Android XML). > > On Tuesday, April 2, 2019 at 9:14:22 PM UTC+3, Oscar Otero wrote: > Seems like I’m trying to create a spec based in gettext, but not, I want a > spect that can fit in all use cases. > >> 1. For intl passing $translator->translatePlural(‘You have %s likes’, $n) >> makes no sense. It basically does not care about $n when obtaining a message. > Ok, you don’t have to use it. Currently there are many libraries not > supporting plurals, that is why it’s a different function. In fact, in some > languages the messages can change not only for plurals but also genres (male > and female) and this is something not included in most libraries. > >> 2. intl has its own message source, it makes little sense storing messages >> in gettext's PO/MO: https://www.php.net/manual/en/class.resourcebundle.php >> <https://www.php.net/manual/en/class.resourcebundle.php>Ok, I didn’t know it >> (I’m not very familiar with intl extension). But I don’t see why >> $translator->translate() cannot be implemented with ResourceBundle class >> internally. Even in intl the formatters and message storing are in different >> classes. > >> 3. Like in gettext there could be message storages that may obtain messages >> differently for plurals / ordinals etc. These may depend on parameters >> different than a number of items. > Can you provide an example of this? > > If you prefer to create a different proposal to illustrate your vision, it > would be clearer to me. > >> El 2 abr 2019, a las 19:49, 'Alexander Makarov' via PHP Framework >> Interoperability Group <[email protected] <>> escribió: >> >> Because plurals aren't done this way in intl and because you are getting >> gettext-specific thing (separate parameter for plural messages) in the >> interface. >> >> 1. For intl passing $translator->translatePlural(‘You have %s likes’, $n) >> makes no sense. It basically does not care about $n when obtaining a message. >> 2. intl has its own message source, it makes little sense storing messages >> in gettext's PO/MO: https://www.php.net/manual/en/class.resourcebundle.php >> <https://www.php.net/manual/en/class.resourcebundle.php> >> 3. Like in gettext there could be message storages that may obtain messages >> differently for plurals / ordinals etc. These may depend on parameters >> different than a number of items. >> >> On Tuesday, April 2, 2019 at 8:23:20 PM UTC+3, Oscar Otero wrote: >> Why not? >> >> - The translator returns the translations for each id >> - The formatter insert the real data in the message >> >> Let’s say we use gettext: >> >> ``` >> $n = count($likes); >> >> $title = $translator->translate(‘Welcome to :sitename’); >> $message = $translator->translatePlural(‘You have %s likes’, $n); >> >> echo $formatter->format($title, [‘:sitename’ => ‘PHP Fig’]); >> echo $formatter->format($message, [$n]); >> ``` >> >> >> Now using MessageFormatter from the intl extension: >> >> ``` >> $message = $translator->translate(’Today is {0, date, full}’); >> >> echo $formatter->format($message, [$datetime]); >> ``` >> >> Here, the translator returns the message that can be in any language >> (english, spanish, italian, etc) and the formatter is what execute >> MessageFormatter->format() internally. >> >> Of course, if you only need english, you may need only the formatter, but if >> your project is multilanguage, you need a way to get the unformatted >> messages in each language (intl extension does not provide this feature, >> AFAIK) >> >> >> >> >> >>> El 2 abr 2019, a las 18:33, 'Alexander Makarov' via PHP Framework >>> Interoperability Group <php...@ <>googlegroups.com >>> <http://googlegroups.com/>> escribió: >>> >>> 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 >>> <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 <php...@ <>googlegroups.com >>>> <http://googlegroups.com/>> 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, pipfros...@ <>gmail.com >>>> <http://gmail.com/> 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 php...@ <>googlegroups.com <http://googlegroups.com/>. >>>> To post to this group, send email to php...@ <>googlegroups.com >>>> <http://googlegroups.com/>. >>>> 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 >>>> <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 php...@ <>googlegroups.com <http://googlegroups.com/>. >>> To post to this group, send email to php...@ <>googlegroups.com >>> <http://googlegroups.com/>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/4925e8d1-f6a9-405a-9efb-2aa4c30dae04%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/4925e8d1-f6a9-405a-9efb-2aa4c30dae04%40googlegroups.com?utm_medium=email&utm_source=footer>. >>> For more options, visit https://groups.google.com/d/optout >>> <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/b95808bf-3302-4e83-a095-080b80ae0231%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/b95808bf-3302-4e83-a095-080b80ae0231%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/c610e7dc-e905-4128-841c-260b039bd47c%40googlegroups.com > > <https://groups.google.com/d/msgid/php-fig/c610e7dc-e905-4128-841c-260b039bd47c%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/AD08019B-E94F-4B55-AAF7-FB284D5BF3FE%40gmail.com. For more options, visit https://groups.google.com/d/optout.
