I would be interested in helping out with this if a WG was to be formed. I can also reach out to Crowdin who I have a really good relationship with to help us with localization nuances.
/vr Nikos Dimopoulos On Thursday, April 4, 2019 at 5:01:18 PM UTC-4, Larry Garfield wrote: > > On Thu, Apr 4, 2019, at 2:33 PM, Oscar Otero wrote: > > 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 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. > > The preference if there is enough interest is to form a working group > early rather than later and then work out of a repo in the FIG organization > directly. > > It definitely sounds like there's potential here for a good PSR. > Localization is definitely something that is hard for stand-alone > libraries to do in a way that's going to play nice with different > frameworks, but at the same time many/most won't have much text to begin > with aside from exceptions. Still, potentially worthwhile. > > If you wanted to form a working group and make a proposal to the Core > Committee, what I would recommend is: > > * Find an editor; it could be one of the people in this thread or someone > who has a crapton of experience in dealing with translation systems (or > preferably both). > * Find 3-5 additional people with experience in this area. Bonus points > if they maintain a translation library, or the translation subsystem of > some major framework/application. Extra bonus points if they speak some > language other than English/French/Spanish natively (since things like > plurals get really weird in many non-Romance languages that a native EFS > speaker wouldn't even think about). > * Put forth that list of people here with a baseline proposal (NOT a spec, > just a goal and scope for a spec) and solicit interest from potential > Sponsors. You probably won't have much trouble getting one of the CC to > Sponsor this one. > * The Sponsor can coordinate calling a vote to approve the WG. > > To the topic itself, I've seen two models of translation: One inlines > English in the code and uses that as the key to translate to other > languages; the other inlines some arbitrary lookup key, and then that key > is used to look up every language, English included. I don't know which is > more common/better, just that I've seen both. I would also suggest that > the developer experience of a library author writing a library should be > paramount, as if it's not easy for them to do, they won't do it, and it > will be very hard to retrofit later. > > Though it pains me to say, it's probably worth reaching out to someone in > the Drupal translation team to participate. They have a *lot* of really > deep work in translation nuance that most wouldn't, and would be very > useful here in defining the problem scope if nothing else. > > --Larry Garfield > -- 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/a9aba0dd-ffa0-4755-ae47-1f3af96f0b32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
