Sys - Translation country code must be lower case

[adrian-moisa]

Locale class use upper case for country code in dart. But i18n is found to use lower case for identification. The 'zh_CN' and 'zh_HK' needs to change to 'zh_cn' and 'zh_hk' for i18n to select the correct translation.

Original issue: singerdmx/flutter-quill#868

[kairan77]

I suggest get rid of i18n altogether by design, display english by default if a generic function hook argument is not provided, let users decide what i18n strategy they should use, their aren't many categorically different places to display text anyway.

[adrian-moisa]

@kairan77 I saw you mentioned this issue in your first message. Can you please detail how having an internal solution for i18n impacts the developers using Quill/VE? I guess you want to take control over the translations and have on solution. But then many other devs wont be eager to have to provide translation for the editor itself.

[kairan77]

https://pub.dev/packages?q=i18n

returns you a list of i18n solutions,

i18n,
flutter_translate,
fast_i18n,
slang,
flutter_i18n,
i18n_extension

etc.

I have 6 different QuillEditor library each one using a different i18n solution,
They are called

QuillDumbEditor 3.0 -> i18n,
QuillDumberEditor 2.7 -> flutter_translate
QuillDumbestEditor 1.9 -> fast_i18n
QuillSmartEditor 8.8 -> slang
QuillSmarterEditor 0.6 -> flutter_i18n
QuillSmartestEditor 666 -> i18n_extension

do you really think it is any more fun importing the mapping files 5 more times and setting up providers 5 more times for all those 5 more different i18n dependencies each of those 6 smartass infrastructure lib decide to use, than being eager to provide the mapping translation once for all for MY language?

Please be nice to your peer dev users, and use common sense, don't over engineer.

in quill, provide a i18n hook method callback in the constructor like

ToolBar(
...
i19n: myTranslationCallback
...
)

Eidtor(
...
...
i19n: myTranslationCallback
...)


String myTranslationCallback(String key) {
  return myPreferedI18nStrategy.translate(key);
}

there are only about 20 to 30 labels that need to be i18ned in quill,

in those places,

just do

Text(widget.i19n?.call('Undo')??'Undo')

Text(widget.i19n?.call('Copy')??'Copy')

As a user of many quill libraries, I choose to write those 3 lines of code every single time.

I know this issue is just due to a careless bug that is easily fixed, but the issue itself is missing the point. Infrastructure lib should not bring in those bullshit library to begin with. I dont' see any real cost or INsummountable difficulty in ditching i18n in quill, if you so rather wish to be helpful to the userbase, just layout the mapping files for languages you had, let users decide what to do with them.

That's just my opinion, feel free to design otherwise, I will mod after your refactoring to get a bare minimum version of the editor later anyway.

[adrian-moisa]

@kairan77 I see what you mean with the i18n proposal and I think your arguments have merit. I guess the current design found in Quill was selected to be easy to use by the many inexperienced users. We can keep the existing translations and export them as consts to be used with your proposed API. Though at the same time I'm a bit puzzled. Why would you want to translate the editor locally instead of adding the missing translations you need in the repo.