ankon
commented
6 years ago I know that this is seriously late, but adding a bit more context here: #111 attempted to fix this issue by providing two new options that would allow to parse the Transifex format, which might look like it actually is equivalent to what this issue wants.
Unfortunately that wasn't true, and we missed that change to go in: #111 still works with a proprietary format (now in a couple of variations), and the functionality of the app-localize-behavior is still tied to having data available in those formats. The aim of this issue was actually to allow adding arbitrary formats by just providing the extractTranslation function. https://github.com/Collaborne/app-localize-chrome-i18n-mixin for example uses that to actually provide support for Chrome i18n files.
I'm not sure whether it makes sense to pursue this approach further here now, maybe one of the maintainers could provide some guidance: Would it be better to just completely fork this behavior for the Chrome i18n support? Should we aim to merge the Chrome i18n support into this behavior?
<app-localize-behavior>hardcodes how translations are extracted from the resource file. This constraint causes various limitations raised by users:As the translation file format is proprietary to
<app-localize-behavior>, it requires a build step to transform translation files provided by translation tools. For example, Transifex offers a JSON Key/Value format that is very similar to the<app-localize-behavior>format (https://docs.transifex.com/formats/json) - except that it doesn't have the language node. Today, this requires a build step to transform the Transifex JSON files into a<app-localize-behavior>resource file.Allowing users to provide their own function to extract translations from the resource file would make
<app-localize-behavior>suitable for a broader usage.