Quasar: Internationalization

[rstoenescu]

[rstoenescu]

Pushed some commits (available in v0.8.2) for Datetime internationalization.

[mikeburgh]

Wonder what your thoughts are on this in terms of copy/text.

The key goals I see for a solution:

• keep components modular and able.to only depend on what they require
• avoid having to send to the client all languages on initial rendering (perhaps set a default and then Ajax to load other language strings)

It would be ideal to be able to keep the strings with each component and on build create the various files per lang with all the strings from each component and inject a default language into the initial code pack.

[laurentpayot]

@mikeburgh for now I'm using kazupon's dynamic locales in my App.vue (v0.8) created hook.
@rstoenescu there is a nice set of i18n features that was developed for meteor-vue.

[rstoenescu]

@laurentpayot yes, kazupon is the right way to go for i18n. However we're not talking about this. Quasar requires i18n translations for a few components, otherwise, for example, you're going to get stuck with "OK" and "Cancel" buttons no matter the language :) This will soon get fixed.

[smolinari]

On the loading translations bit. I would say, only the currently selected language of the user (or default for guests, if you have them), should be loaded initially. I'd also venture to say, only the language phrases needed for the currently rendered components should also be loaded. Not sure if that matters or is feasible, but it is how I think i18n and L10n systems should work to be effecient as possible, especially for mobile.

Scott

[rstoenescu]

@smolinari We're on same page here. Thank you for your thoughts!

[murbanowicz]

Is 24hr format part of it or should be referenced in DateTime issues?
Do we have 24hr format written down somewhere? It is important.

[rstoenescu]

Just added a ticket for it #271
It's high on my priority list at the moment.

[rstoenescu]

Just a few components use some labels that need translated, but managed to add props for them, so developers can use whatever labels they want to replace default ones.

It seems overkill for dev to handle Quasar i18n files just for a few labels. If in the future more components will require this, then an i18n system will be put in place. Until then, using props will suffice.