Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All .arb translations files from CrowdIn have an invalid "@@locale": "en" and are not loaded #43

Closed
stephanegigandet opened this issue Dec 26, 2020 · 10 comments
Assignees

Comments

@stephanegigandet
Copy link
Contributor

e.g.
l10n/intl_fr_FR.arb:
{
"@@Locale": "en",
[..]

If this cannot be fixed in the CrowdIn setup, one option could be to have a script to fix the files, that we would run whenever we check-in new translations.

@stephanegigandet
Copy link
Contributor Author

In fact when trying to switch to the new Flutter internationalization introduced in Flutter 1.22, I get this:

flutter pub get
The locale specified in @@locale and the arb filename do not match. 
Please make sure that they match, since this prevents any confusion 
with which locale to use. Otherwise, specify the locale in either the 
filename of the @@locale key only.
Current @@locale value: en
Current filename extension: aa_ER
Generating synthetic localizations package has failed.
`````

I guess one option is just to remove the @@locale :) 

@stephanegigandet
Copy link
Contributor Author

Interesting, if I have one app_en.arb + app_fr_FR.arb, Flutter complains I don't have app_fr.arb

flutter pub get
Arb file for a fallback, fr, does not exist, even though 
the following locale(s) exist: [fr_FR]. 
When locales specify a script code or country code, a 
base locale (without the script code or country code) should 
exist as the fallback. Please create a {fileName}_fr.arb 
file.
Generating synthetic localizations package has failed.

@monsieurtanuki
Copy link
Contributor

For the record, in my other flutter projects I use simply one json translation file per language.
Something like that:

{
  "version": "version #versionNo#",
  "website_menu": "Website",
  "feedback_subject": "About the “#app#” app",
  "feedback_menu": "Contact us",
  "fallback_email": "No mail app found!",
  "fallback_url": "No web browser found!",
  "share_app_subject": "“#app#” app for smartphone and tablet",
...
}

Then, I just call something like AppLocalizations.of(context).translate('feedback_menu').
Et voilà !
No hassle. No pre-compilation. Parameters if I want. Just json files.
I haven't had a look at the new flutter way to deal with translations, but I doubt it can be much simpler than my version.

monsieurtanuki added a commit that referenced this issue Dec 26, 2020
@stephanegigandet stephanegigandet self-assigned this Dec 26, 2020
@stephanegigandet
Copy link
Contributor Author

I use simply one json translation file per language.

Right, all the .arb files etc. certainly seem like overkill now. They'll be useful once we have a cool working app that we want to ship in 200 countries. When we add new translations then, using CrowdIn translators will be able to add them, and they won't have to use git.

@monsieurtanuki
Copy link
Contributor

I'm not against the concept of translations. I'm again painful processes, and I guess the CrowdIn process could generate json files. Such a suggestion, I won't fight about that.

@stephanegigandet
Copy link
Contributor Author

I guess the CrowdIn process could generate json files.

It can, we use a json file through Crowdin for another sub-project: https://github.com/openfoodfacts/openfoodfacts-hungergames/blob/master/src/i18n/common.json

At this point I'm just trying to do whatever is the recommended way of doing things in Flutter, in the hope that it will be easier for newcomers going forward.

To be honest there are tons of things that I find painful in Flutter (like defining all those nested classes to read a JSON file instead of just accessing values with a syntax like some_hash{some_key}{some_other_key_for_an_array}[10]{another_key} like I'm used to do in Perl or JS). So I do find the internationalization things painful, but not more than the rest. :)

@stephanegigandet
Copy link
Contributor Author

Of course I'm barely scratching the surface of discovering Flutter, so I'm sure there are good reasons for most of the things that I find painful, and hopefully they won't be painful once I understand more about how things work in Flutter.

@monsieurtanuki
Copy link
Contributor

Of course that's the normal way to access Map fields; I mean, in flutter/dart too.
I don't why in this project you have to declare the type of an empty List.
I highly recommend the flutter training by https://www.appbrewery.co (https://www.udemy.com/course/flutter-bootcamp-with-dart/?referralCode=2B7724A180C0502A2547)
For 12 euros...
Then you'll realize that the translation management is the only painful thing in flutter...

And I don't think there are good reasons for painful programing. For instance I would always discourage people from starting Android/java (Kotlin would be the same I guess).

@stephanegigandet
Copy link
Contributor Author

I highly recommend the flutter training by https://www.appbrewery.co (https://www.udemy.com/course/flutter-bootcamp-with-dart/?referralCode=2B7724A180C0502A2547)

Thanks, I started it.

@stephanegigandet
Copy link
Contributor Author

Fixed by PR #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants