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]. 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/cf274691-629f-402a-b6ff-9d2adf9e570c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
