I am developing yet another bmi app and I want it to be useful also for Americans using non-SI units like foot and pound. But I don't like to add an extra button to switch between units. I would rather use the system settings to automate that. The class java.utils.locale seems to be useful. But how do I access that in my App Inventor program?
use the tools extension and its Country and/or Language method
Returns the country/region code of the current Locale, which should either be the empty string, an uppercase ISO 3166 2-letter code, or a UN M.49 3-digit code.
Returns the language code of the current Locale.
Related
I'm using the places api to search for places and quickly copy the some customer information into the front-end of my application.
But sometimes, the name gets translated to English, which is not desirable for the user. How can I avoid the translation of certain places?
For instance: Krankenhaus Göttlicher Heiland will be translated to: Hospital of the Divine Savior. It kinda sounds cool, but it's not what the user wants... :)
I know it takes default my browser settings and that you can add language on in the parameters, but I want to turn that off completely. So get the original native names.
Any idea?
Some places on the map is labeled with Cyrillic names, but I need only English/Latin names of places on the map, however sometimes there are only local names. How can I implement this?
P.S.: I have spotted this issue on Belorussian and partly on Russian places.
Screenshot
About languages in general: after all, it depends on which languages specific placename is tagged with. OpenStreetMap has always "local" variant in local primary language, and CARTO Mobile SDK uses this by default, but the data has also other languages, so you can control it as following.
CartoVectorTileLayer (both CartoOnlineVectorTileLayer and CartoOfflineVectorTileLayer are subclasses of it) has method setLanguage(String) to select language, so e.g.:
layer.setLanguage("en");
will give you English language maps.
In SDK 4.0.2 SDK and nutiteq.osm tile source you can use following languages: local/default, en, es, de, fr, it, ru, zh (Chinese), tr (Turkish) and et (Estonian) as language
With latest CARTO SDK 4.1.0 and new carto.streets source you can use any OSM language. I would suggest to configure map based on device language settings, with something like:
// Android
layer.setLanguage(Locale.getDefault().getLanguage());
// iOs / Xamarin
layer.Language = Foundation.NSLocale.PreferredLanguages[0].Substring(0, 2);
What if specific name is not available in given language? Then the MapView will fallback to 'local' language by default, the map will not be empty. But if the 'local' language is still unreadable, so I'd prefer latin alphabet names? In SDK 4.1.0 you can configure primary and secondary fallback languages, e.g. you set primary language to 'de' for Germans, then to avoid strange alphabets (say Hebrew, Greek, most of Asia) set 'en' as primary fallback; then local is used only if both your primary and English names are missing:
layer.FallbackLanguage = "en";
Now I know you want automatically transliterated / Romanizied names, so even if source data from OpenStreetMap has e.g. names in Cyrillic only (Russia, Belorussia etc), then it would show them in Latin chars. It is not exactly same as translation, e.g. Moscow would become Moskva with Romanization, but can be helpful for many cases, actually with all none-Latin scripts, especially from Asia (Chinese etc). The problem here is that many languages, including Russian have many competing Romanization rules, so even if we would want to, then we could not do it in general SDK map rendering level. Our CARTO SDK may provide API for app to apply your preferred translation table, but we do not have this anyway. The SDK is open source and you are welcome to provide patch for the feature. I added issue ih the project for this: https://github.com/CartoDB/mobile-sdk/issues/147
In an application that is internationalized, I have code like this:
_comboBlah.Items.Add(pct.ToString("P0", formatInfo));
where formatInfo is normally from the CultureInfo for the current UI language (which might well be different from the CurrentCulture. I was surprised that when "en" is the UI language (and incidentally also the CurrentCulture), the value of formatInfo.PercentPositivePattern is 0 (meaning that the number and percent sign will be separated by a space). Since this is not the normal way to format percentages in English (U.S.), I went into Regional and Language Settings to see if I could see why it was set this way and change it to format without the space (PercentPositivePattern = 1). I couldn't find any way to set this in the Windows UI. Is there a way? Anyone know why this is the default? (It's not the default in Excel.) Is there any way around this besides changing it programmatically when "en" is the UI language? Is there any hope that MS got it right for other built-in locales?
I'd expect the base file to contain my English words since my project has "Localization native development region" set to English.
Update - to clarify my question:
Apart from addressing question what language end-users will see, you need to consider also what will be shown in the AppStore.
My current experience is that if you use Base for English, English won't appear in list of supported languages (how Apple knows in which language your base localization is) in the description of your app.
I've met this issue myself - base (English), German and Russian
Target settings refer to:
Localization native development region = en
But on Appstore it appears in this form:
Languages: German, Russian
no reference to English
I consider to duplicate base localization to English (not a high priority, as users see from screenshots that App works in English anyway)
Edit: there seem to be a different behavior in iOS8 - Application Settings (Settings.bundle) seem to ignore Base translation, if any of translations match your "Preferred Language Order".
In other words, App is localized: Base, German, Russian.
iPhone is configured to use English, preferred languages order is English, German, Russian.
Application settings come in ... German!
Once again: this is applied to Settings only not to the application itself!
Although I am not entirely sure if I get this correctly, I will try to answer your question TTBOMK.
Suppose you’re using NSLocalizedString(key, comment) from in your code. You can clearly see that the first argument is actually is a key for a string, rather than the translated (or to be translated) string itself. Therefore when you “write code” you actually don’t write strings in base language — or any other language for that matter. You should think it as if you're adding string placeholders in your code.
Later on, you’re supposed to create a Localizable.strings file for each language you would like to support, in the form of key = value;. To make your UI appear at least in one humanly–readable language you should at least have one Localizable.strings file with proper string values for each placeholder key.
For example: if you had NSLocalizedString(#“ConfirmationButtonTitle", #“Yada yada”) in your code, then it makes totally sense having a Localizable.strings file that contains ”ConfirmationButtonTitle” = “Tap here to confirm”; element in it. If you don’t create a Localizable.strings file or no Localizable.strings file contain ConfirmationButtonTitle key, then button title falls back to ConfirmationButtonTitle, since it is the name of the placeholder key.
Having said that, most people prefer naming their keys exactly as string values for various reasons. This is arguably a convenient — and very common — practice, but could lead to conflicts in people’s minds.
So, if you were to create the previous NSLocalizedString example like NSLocalizedString(#“Tap here to confirm", #“Yada yada”) instead, then your default/base Localizable.strings file would probably contain an element like “Tap here to confirm” = “Tap here to confirm”;.
What happens here isn’t that you’re repeating yourself, but instead you’re naming your key exactly as your base language’s string value, that’s all.
EDIT
There always have been a base language concept, but as I understand it Xcode 5 emphasizes this even more: that’s good. If your base language is English, then you don’t have to have a Localizable.strings file for English, again.
According to the documentation (scroll down to Creating Strings Files for User-Facing Text in Your Code), you shouldn't add Localizable.strings to the Base localization. Even if your development language is English, create a separate folder and Localizable.strings for English. Create others for each additional language you want to add.
Further reading
Managing Strings Files Yourself
Localizing Your App
Internationalizing the User Interface
iOS Localization Tutorial
Working with Localization in iOS 8 and Xcode 6
What’s new in localization in Xcode 9 and iOS 11
I used the instructions from here:
http://www.playframework.org/documentation/1.2.1/i18n
and created files for different languages.
I call play.i18n.Lang.change method to change the language file,
and it still takes the captions from the English file ("messages" without a suffix),
Any ideas why?
It is hard to know from your description exactly what the problem may be, so I have outlined how you should do a multi-lingual app.
There are a number of steps you must follow to get internationalisation to work. Firstly, you must change your application.conf file to declare your supported languages.
So, if you are supporting English and French, you would do
application.langs=en,fr
You must then create the language file for your French translation called messages.fr. The English language would just stay in the standard messages file. In this new file, add your name value pairs for the key and message.
The way Play processes the messages, is to look first in the locale specific message file first (so for english it would be messages.en, which does not exist, and for french it would be messages.fr). If the message cannot be found in the locale specific message file, it will look at the global message file. So your global messages file acts as the catch all.
Then, in your code, set the language for your particular user, using
Lang.change("fr"); // change language to French
Remember, that this will save a cookie for the particular user in a PLAY_LANG cookie, so check that this cookie is being created for the user.
Final note, make sure that your files are UTF8 encoded. It causes problems if it is not.
In my specific case I had
play.http.session.domain
set to something else other than localhost while testing.