How to detect the Language set in the Windows phone - windows-phone-7

I need to detect the language of the phone so that I can display the message accordingly. If it is english , then display english. Say, I target a few countries such as China,japan, Korea. How do I do it? here my incomplete code to show what I mean:
tring StrLanSetOnClient;
string strLanEng= "english Msg";
string strLanChn=" Msg in chinese character";
string strLanJpn= "Msg in Japanese character";
string strLanKor= "Msg in Korean character" ;
strLanSetOnClient = CultureInfo..........
If( strLanSetOnClient == "English")
{
txtBlkLan.Text = strLanEng;
}
elseif ( strLanSetOnClient == "Chinese")
{
txtBlkLan.Text = strLanChn
}
....
Thanks
--- Updated Questions:
1) Where should I detect the language? In App.xaml?
2) How all pages can refer to this global variable name?
3) Which is the best practise to detect ? use CultureInfo or thread.currentThread
Thanks
&#lt;?xml version="1.0" encoding="utf-8"?&#gt;
&#lt;Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&#gt;
&#lt;ProjectExtensions&#gt;
&#lt;VisualStudio &#gt;
&#lt;FlavorProperties GUID="{C089C8C0-30E0-4E22-80C0-CE093F11xxxx}"&#gt;
&#lt;SilverlightMobileCSProjectFlavor&#gt;
&#lt;FullDeploy &#gt; True &#lt;/FullDeploy&#gt;
&#lt;/SilverlightMobileCSProjectFlavor&#gt;
&#lt;/FlavorProperties&#gt;
&#lt;/VisualStudio&#gt;
&#lt;/ProjectExtensions&#gt;
&#lt;/Project&#gt;
This is the vanila csproj file of my Wp7 App. There is no SupportCulture tags in it. So, I have to add this tag in it right when I open it with notepad? When I downloaded your sample app, I open the csproj file with notepad, i dont see this tag either? Thanks

The way you're trying to do localization is to get very complicated, have lots of duplication and be difficult to change in the future.
There is a built in way of supporting multiple languages/cultures/etc. See http://msdn.microsoft.com/en-us/library/ff637522(v=vs.92).aspx

I wrote a blog on this very subject just the other day. It describes how to localize from start to finish, and it is located at www.hopnet.mobi, click Blogs.
Once you get the hang of it, localization really isn't difficult at all. I've localized one app, and I'm waiting on a friend to validate my translations. While she's doing that, I'm localizing the other apps. More languages means wider distribution, which means more money. You're doing the right thing!

Use CurrentCulture which is in your System.Globalization namespace. It has properties like Name, EnglishName, DisplayName and NativeName so you pick which one suits you most.
EDIT: Detecting the language will depend on whether you want to allow users to change the language or not. If not then detect it in App.xaml.cs and store the information in an IsolatedStorage object so that you can share it among different pages. This way you can avoid detecting the language settings later and just rely on the saved settings. As for the best practice I stick to CultureInfo. I never tried going directly through Thread.CurrentThread.

Related

TWINE game localisation

Do anyone know if it is possible to localise a TWINE game? I’d like to have my interactive stories in all the Scandinavian languages. I also plan to have mp3 spoken narration in each language for non-readers at a later stage. My thought was to maybe have one complete story file per language but it seems like a hard thing to maintain.
Do anyone have a best-way of doing this?
It may be possible to localize your Twine game's default UI strings, depending on your story format. For example, if you're using the SugarCube v2 story format in Twine, then there are some SugarCube localizations here.
However, for your story text it's entirely up to you how you handle displaying that based on the user's choices. Again, assuming you're using SugarCube, you might have the user select the language in the beginning like this:
<<set $lang = "EN">>
''Select your language:'' <<listbox "$lang" autoselect>>
<<option "English" "EN" >>
<<option "русский" "RU">>
<<option "українська" "UK">>
<<option "Türkçe" "TR">>
<</listbox>>
That will give you a dropdown list of language options.
Then, in each of your passages, you would have something like this:
<<switch $lang>>
<<case "RU">>
(Russian version of passage.)
<<case "UK">>
(Ukranian version of passage.)
<<case "TR">>
(Turkish version of passage.)
<<default>>
(English version of passage.)
<</switch>>
You could put any non-language based code outside of that "switch" macro.
If you're using something other than SugarCube for your story format, then you'll likely use something similar to that.
Hope that helps! :-)

How to implement a language / culture (that is not yet supported) in ActiveReports 11?

We already have a vast group of .rpx files that contain report definitions in german. We have used scripting to translate some of the text to romansh (official swiss language used by <1% of population), yet it has been requested.
The vision now is to create reports in french and maybe italian as well. Yet we are well aware that the current scripting approach like:
if (txtSprache.Text == "RM")
{
lblAbonnentenNr.Text = "Abo-nr.:";
lblAbrechnungVon.Text = "Quen dils:";
lblBis.Text = " -";
lblZahlbarBis.Text = "Pagabel tochen:";
lblObjekt.Text = "Object:";
lblRechnungsNr.Text = "Nr. dil quen:";
lblRechnungsdatum.Text = "Datum da quen:";
lblERechnungsID.Text = "ID";
lblAbonnent.Text = "Abonnent";
}
Is not well suited for that. I have been asked to create options for I18n support. Quoted from the AR11 documentation:
To localize a Report at design time
1. Click the gray area around the design surface to select the Report in the Properties window.
2. In the Properties window, drop down the Culture or Language property and select the culture that you want to apply to the report.
The old default was: (default, inherit), I know changed that to German (Switzerland). I couldn't find any difference, no new stuff under C:\Program Files (x86)\GrapeCity\ActiveReports 11\Localization, nor elsewhere in the xml.
How do I add a new language sheet / values for the current report and it's labels?
How do I add a culture that does not exist yet? (In worst case I'd use any local and use it as romansh, since only german, italian, french and unlikely english could be used)
The Language property, mentioned in the documentation, works for the code-based templates only. When you set the new language by this property VSID creates the additional resource file, e.g. myreport.jp-JP.resx.
In such case, the compiled report will upload the needed resources according to CurrentThread.CurrentUICulture value. It does not work for RPX(xml-based) templates.
So if you want to use this functionality, you need to convert xml-based to code-based templates.
The Culture property helps only to specify a locale for OutputFormat feature(e.g. conversion to currency).
For RPX templates localization, I think you could combine the external localization resource files with the current scripting approach, I mean the loading of the resource file in script and update the report items.
Thanks,

WinRT Localization - Multiple Translations per Language

I am building a Windows Store application in XAML/C# for a Windows 8.1 Professional environment.
My project has a requirement that I must support multiple languages in addition to multiple translations for any given language. For example, I may have a label that would be displayed in English or French, but in English it may need to display the word "Title" or the word "Heading" depending on the customer's preferences.
My issue is that I cannot figure out a way to package and switch between multiple resource dictionaries for the same language while still using the built-in localization functionality provided by XAML for WinRT (i.e. using the Uid property on my controls to bind them to a resource dictionary).
I've noticed two functions, ResourceManager.LoadPriFiles and ResourceManager.UnloadPriFiles, that I thought might allow me to swap out resource dictionaries at runtime, but I can't figure out how to get the PRI files to be package outside of the application's main resource map to allow the loading and unloading.
I've also considered creating a custom data binding or converter that I could use to bind the controls' text manually, but that would cost me the ability to see labels at design time in Blend as well as sacrificing the convenience of the built-in localization capabilities.
Another option was to compile a separate instance of the application for each of the custom translations the customer might require, but obviously that's not a very maintainable way of solving the issue...
Finally, I had considered repurposing something like the homeregion qualifier of the ResourceContext to solve the issue; however, that seems very limiting as there are already pre-established homeregions that I would have to choose from. Repurposing fields seems like a bad idea in general.
You can use several resources files and use the PrimaryLanguageOverride property to select a different language than the default one. This will allow you to change the current resources set without doing anything specific.
You can use a structure like this one for your resources:
Strings
+- en-US
+-Resources.resw
+- fr-FR
+-Resources.resw
+- fr-other
+-Resources.resw
Then in you code, you will just have to call any of the following lines :
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = "fr-other";
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = "en-US";
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = "fr-FR";
You application will now use the "fr-other" language. You can use up to 8 characters in the second part of the language tag.

Is it possible to set PercentPositivePattern in Windows UI?

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?

Do I need English beside Base localization which would contain the exact same 'translation'?

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

Resources