How to localize the app: strings/numbers/pluralize strings etc.

[dawehner]

Drupal worked a lot throughout the years to get a good localization support in PHP. For example we do support pluralized strings properly: Every language has potential a different concept of pluralization (1, 2, 5, 10 for example).

Let's discuss in this issue which features we need and how to not move ourself into an edge case

Features we need | keep in our head

• String localization
• Do we want people to manage these strings through Drupal somehow?
• Proper string pluralization

Useful libraries

• https://github.com/yahoo/react-intl

[pixelmord]

A couple of thoughts on this:

• The string translation interface could benefit from a revamp where my most requested feature would be case insensitive search and search/filtering by context
• Also "on page" translation should be supported sort of the way "i10n_client" handles that
• And ideally we could expose components as libraries for the various frontend frameworks as drop-in solutions for more tightly coupled apps that run from within the context of a drupal page or block so that they can use a component that acts as -- a wrapper for the Drupal.t -- a inline editing solution for a given role

React example (super brainstorm™) : <Drupal.t string="my text @arg" context="app" args={{arg: 'hello world'}} editRole="administrator" />

[pixelmord]

I can take a stab at components for translation and formatPlural that use the Drupal.t() and Drupal.formatPlural() functions respectively. Will create a PR for that...

[dawehner]

Keep in mind. You won't have a normal Drupal environment here. Drupal.t/Drupal.formatPlural won't just work

On Mon, 26 Mar 2018 at 18:59 Andreas Sahle notifications@github.com wrote:

I can take a stab at components for translation and formatPlural that use the Drupal.t() and Drupal.formatPlural() functions respectively. Will create a PR for that...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jsdrupal/drupal-admin-ui/issues/11#issuecomment-376256562, or mute the thread https://github.com/notifications/unsubscribe-auth/AABz7lw7gL8RmP2e1LUBIrEHenOieKU4ks5tiSyDgaJpZM4Sn4zV .

[pixelmord]

Ah my bad, I did not look closely at how the APP is rendered and thought we might have the Drupal JS available, so that complicates things there... So if we want to benefit from Drupal translation we need to either build sth custom or hook up a lib like react-intl with a "backend", need to do some research on that

[pixelmord]

May be sth along those lines here: https://www.i18next.com/add-or-load-translations.html

[tedbow]

Do we want people to manage these strings through Drupal somehow? I think this would important. There will be a lot of strings such as "Access denied" that will need to be translated in both php server-side and client-side.

Could we make an API call at the beginning of the APP being load that sends a list of untranslated strings and expects back the translations in a given language?

[dawehner]

How do we really know the list of strings some route will need at some point?

Maybe a good way would be to parse the routes on a build step, similar to what we do right now in Drupal core.

On Tue, 27 Mar 2018 at 14:18 Ted Bowman notifications@github.com wrote:

Do we want people to manage these strings through Drupal somehow? I think this would important. There will be a lot of strings such as "Access denied" that will need to be translated in both php server-side and client-side.

Could we make an API call at the beginning of the APP being load that sends a list of untranslated strings and expects back the translations in a given language?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jsdrupal/drupal-admin-ui/issues/11#issuecomment-376521398, or mute the thread https://github.com/notifications/unsubscribe-auth/AABz7jYSjElCzqd2fR5h-awcat7dbeBHks5tijwRgaJpZM4Sn4zV .

[tedbow]

I don't know the reasons for the way Drupal does Drupal.t() but always wondered if would simplier to always use tokens of strings in the JS code like `Drupal.t('[ACCESS_DENIED]'). So this would pull from a list of translated strings.

Then it would be easy to send that list to be translated in a API call.

Could we do something like that?

[dawehner]

I don't know the reasons for the way Drupal does Drupal.t() but always wondered if would simplier to always use tokens of strings in the JS code like `Drupal.t('[ACCESS_DENIED]'). So this would pull from a list of translated strings.

Well, there is code in Drupal which scans existing JS files to know all translatable strings and then exposes all of them. If you look at https://github.com/yahoo/react-intl they all come with an ID and some default value. This way you can always translate / adapt the english string over time without having broken translations.

[pixelmord]

So to summarize:

Goals:

1. we want to localize the app
2. we want to use a well known React i18n lib that is built on standards
3. we want to leverage the existing Drupal i18n APIs and l10n ecosystem
4. we want to configure the language(s) of the app (as well | the same way) as the one of the Drupal backend

For the above points we need to:

1. start from the beginning to use an api provided by the lib selected in 2. to avoid massive refactoring from plain hardcoded strings to localized strings later.
2. use yahoo/react-intl because it seems to fit the bill both by its widespread use, features and being built on standards
3. figure out a) a way to match the strings used in the app to existing ones on the Drupal l10n server and the associated backend storage where additions and overrides may exist. b) to load those strings via REST c) a way to do performance optimization in terms of bundle splitting, lazy loading etc. per route...
4. CRUD language and translation config REST API and provide configuration pages for that in the app as well as sth like a language switcher/language detection that respects the Drupal config

I see no blockers to start with 1. 2. and 4. right away and in the meantime try to figure out how to best implement 3.

[justafish]

@pixelmord sounds like a good plan! :+1: If this is something you want to actively work on, keep in mind is that we're still futzing around with the general architecture and what not, so I would suggest keeping this experiment isolated to one component as a proof-of-concept

[pixelmord]

On it.