Titanium JIRA Archive
Appcelerator Community (AC)

[AC-6619] Not setting 'en' folder in 'i18n' causes to not retrive other localizations

GitHub Issuen/a
TypeBug
Priorityn/a
StatusOpen
ResolutionUnresolved
Affected Version/sAppcelerator Studio 4.5.0
Fix Version/sn/a
ComponentsAlloy, Appcelerator CLI
Labelsandroid, internalization, localization
ReporterPietro Granati
AssigneeAbir Mukherjee
Created2020-10-27T11:56:36.000+0000
Updated2020-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.

Comments

  1. Joshua Quick 2020-10-27

    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.
  2. Pietro Granati 2020-10-28

    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 :)
  3. Joshua Quick 2020-10-28

    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.

JSON Source