[AC-6619] Not setting 'en' folder in 'i18n' causes to not retrive other localizations
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | n/a |
Status | Open |
Resolution | Unresolved |
Affected Version/s | Appcelerator Studio 4.5.0 |
Fix Version/s | n/a |
Components | Alloy, Appcelerator CLI |
Labels | android, internalization, localization |
Reporter | Pietro Granati |
Assignee | Abir Mukherjee |
Created | 2020-10-27T11:56:36.000+0000 |
Updated | 2020-10-28T19:18:06.000+0000 |
Description
Today on TiSlack (https://ti-slack.slack.com/archives/C03CVQX2A/p1603729246286000) I finally found the problem that doesn't load my strings causing this warning:
[WARN] KrollProxy: (main) [15,661] No localized string found for identifier: <your string name>
The problem is that during compile I saw GRADLE write:
[GRADLE] warn: removing resource it.yourapp.name:string/<your string name> without required default value.
For every string in my strings.xml file.
*Solution:*
The "default" GRADLE is searching for is the "en" folder in "i18n" insted I had only the "it".
After adding that folder everything is working fine.
I don't know if it fixable but maybe put an info inside the documentation.
This has always been the default behavior on Android. If the app fails to find a string resource for the current locale, it will fallback to "en", and then finally to unlocalized strings under "res/values/strings.xml". https://developer.android.com/guide/topics/resources/multilingual-support So, before Titanium 9.0.0, if you ran your app on a device without an "it" locale, your string lookups would have been
null
on Android. With Google's gradle build system, it's now validating your i18n string resources, logging build warnings if you have any string entries missing under the "en" which is the default fallback, and removing entries so that it behaves consistently in non-english locales. Basically, Google is letting you know your app has internationalization issues. I don't consider this a bug. Especially since a native Android developer would run into the same warnings.I figured out what you say and it makes sense, but, in a normal use if someone coming from 8.x SDK transitioning to 9.x like me creates a bit of confusing and also noone has ever see it: https://ti-slack.slack.com/archives/C03CVQX2A/p1603729246286000 I'm just asking to put in the guide to help others :)
I suppose we can do things to make this easier and turn this into a feature request ticket. Like if you only have 1 language defined, then our build system should just automatically make it the default by duplicating the strings xml to the unlocalized Android
./res/values
folder. However, this won't handle the issue where an app has more than one non-English strings xml files. Another possible approach may be to support a./i18n/default
folder which would become the default strings fallback. On Android, we would just copy that default strings xml to the unlocalized./res/values
folder. We would just have to see what we would have to do on the iOS side for parity. Anyways, those are just some ideas I'm throwing out here, because I do agree with you that it would be nice to make this more convenient for non-English apps.