You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think the translation system is not ideal, mainly because of those two points:
Bundle size
When using Orejime as a standalone script (for example from a CDN), translated strings for all supported languages are bundled with it, whether they're used or not.
A solution to that could be to extract translations for each language into separate js files that could be required individually.
Consistency
There is an overlap in the way translated strings are provided. Some are set in the configuration (like app or category titles and descriptions), while the rest comes from the translations object. In some instances, those two ways are mixed together:
I agree with the solution : I think we could remove all title or description in apps array and use only the property name to reference a translation.
We could also use this technique for the categories.
Here is an example of the categories array could be : categories: [ { name: 'cookies_essentiels_cat', apps: ['cookies_essentiels'] } ]
And the translate array will be : translations: { fr: { "cookies_essentiels_cat": { title: "Cookies essentiels et fonctionnels", description: "...", } }
Glad you agree!
Yes exactly, to be done right this should apply to all translatable strings.
I'll try to gather feedback from more people to ensure it wouldn't cause unexpected problems.
Maybe a good strategy would be to release a minor version allowing every string to be translated, while still allowing the current configuration but showing deprecation notices in the console.
Then, we could remove the "old" configuration in the next major version.
I think the translation system is not ideal, mainly because of those two points:
Bundle size
When using Orejime as a standalone script (for example from a CDN), translated strings for all supported languages are bundled with it, whether they're used or not.
A solution to that could be to extract translations for each language into separate js files that could be required individually.
Consistency
There is an overlap in the way translated strings are provided. Some are set in the configuration (like app or category titles and descriptions), while the rest comes from the
translations
object. In some instances, those two ways are mixed together:A cleaner solution could be to systematize the use of translated strings:
While being more consistent, it would be a little more convoluted.
The text was updated successfully, but these errors were encountered: