I have create a Localizable.strings file with 2 language, en & jp.
en: "key"="english";
jp: "key"="日本";
It works good when using en & jp.
_title.text = NSLocalizedString(#"key",nil);
But when I using other language,like German,the label will display key in the view.I want to show the key of en strings value default.
How to set to load en when the user using other language without en & jp?
you can create a Localizable.strings for "de", and then you can copy/paste from the "en" (if "en" was your main language you don't need to copy/paste, it will be created with the "en" strings)
But it's strange, I have my apps for "en" and "es" and the default is "en". I didn't do anaything.
Related
#State var selectedSpace : FreeSpace = .Big_Bag
Picker("", selection: $selectedSpace) {
ForEach(FreeSpace.allCases) { FreeSpace in
Text(FreeSpace.rawValue.capitalized)
}
}.environment(\.locale, Locale.init(identifier: "az-Arab"))
.foregroundColor(Color("Color"))
.padding(.trailing)
Knowing that the pickerValues
enum FreeSpace: String, CaseIterable, Identifiable {
case Big_Bag, Small_Bag
var id: Self { self }
}
i'm trying to convert what is inside the picker to arabic and can't find a solution it is always displayed in english.
From apple doc :
If you intialize a text view with a variable value, the view uses the init(:) initializer, which doesn’t localize the string. However, you can request localization by creating a LocalizedStringKey instance first, which triggers the init(:tableName:bundle:comment:) initializer instead:
// Don't localize a string variable...
Text(writingImplement)
// ...unless you explicitly convert it to a localized string key.
Text(LocalizedStringKey(writingImplement))
That means that you must use :
Text(LocalizedStringKey(FreeSpace.rawValue.capitalized))
I think you misunderstood the concept of iOS localization. In you app you need to provide localizable strings file (usually it is named Localizable.strings), which holds localization values for your supported languages.
So basically in your project settings, you need to enable desired languages (English and Arabic on the screenshot).
Then you create Localizable.strings file and add it as a resource of your app. Then just make it localizable by clicking localize in File Inspector.
This will let you choose what language you want to use for the current file. Once you make it localizable you can tick what languages to use and you can switch them in Project Navigator.
Since now you will put localized texts in its appropriate Localizable file and use its key to access it.
Then if you use Text(String(localized: "key").uppercased()) you should be fine.
I have a service which gives the language display name as part of response. I want to retrieve the language code so that I can apply the internationalization for output file.
Expected input : English - United States
Output : en_US
You might use something like that:
Optional<Locale> locale = Arrays.stream(Locale.getAvailableLocales())
.filter(l ->
l.getDisplayLanguage().equals("English") &&
l.getDisplayCountry().equals("United States")
).findAny();
locale.ifPresent(System.out::println);
So, I'm localizing an app from japanese to english.
In japanese, there is no distinction between (say) "Mr." and "Ms."(/"Mrs."), so I need to do something like this:
/* Salutation format for user (male) */
"%#様" = "Mr. %#";
/* Salutation format for user (female) */
"%#様" = "Ms. %#";
As you can see, the Japanese localization uses the same string in both cases. I was under the impression that, when the strings file contains more than one entry with the same 'source' (i.e., left side) string, the 'comment' was used to determine which one was employed. It turns out I was wrong, and the comment parameter is just an aid for human translators, totally ignored by NSLocalizedString().
So if I run the app, both of the code paths below produce the same string, regardless of the user's gender:
NSString* userName;
BOOL userIsMale;
/* userName and userIsMale are set... */
NSString* format;
if(userIsMale){
// MALE
format = NSLocalizedString(#"%#様",
#"Salutation format for user (male)");
}
else{
// FEMALE
format = NSLocalizedString(#"%#様",
#"Salutation format for user (female)");
}
NSString* salutation = [NSString stringWithFormat:format, userName];
So, how should I deal with a case like this?
Well, actually “left side” of the NSLocalizedString is a key. So you could do something like:
NSLocalizedString(#"SalutForUserMale", #"Salutation format for user (male)");
NSLocalizedString(#"SalutForUserFemale", #"Salutation format for user (female)");
Then in your base *.strings file (Japanese I presume) you would have:
"SalutForUserMale" = "%#様";
"SalutForUserFemale" = "%#様";
And in your English *.strings file you would have:
"SalutForUserMale" = "Mr. %#";
"SalutForUserFemale" = "Ms. %#";
The Localizable.strings files are nothing more than key value lists. You are using the Japanese phrases as keys which is unusual but I guess it works. I assume this is because the original app was developed in Japanese(?). I usually use English phrases keys, but whatever.
The point is that if you want two different phrases in even just one translation you have to have two different keys in all your translations. If there is something in your base language that is not distinguished but in the translations it is, then you can just "split" an existing key in two new ones. Just change it slightly or add a number, see below:
/* english .strings file */
"hello_world_key" = "Hello World";
"Yes1" = "Yes"; // same in english but different values in german
"Yes2" = "Yes";
/* german .strings file */
"hello_world_key" = "Hallo Welt";
"Yes1" = "Ja";
"Yes2" = "Jawohl";
I have one portal and several communities (LR 6.1 - sites). The communities allocate several regions with different languages, hence I would like set different default languages for each community.
Is it possible to set default language by site?
I need it for CMS requirements: every site has a own default language for content. For example site in Germany must have germany as default language, and site in Spain have a spanish as default language and so on.
I'm not aware that configuration setting for default language per site (if you mean community/organization...) exists.
For entire portal you have "Default Language" option under
Control panel -> Portal settings -> Display settings
But if you don't have your language there, or you want to remove/add some languages you can configure that in portal-ext.properties. For example
locales=hr_HR,en_US
EDIT (more info about bug mentioned in comment)
If you take a look at com.liferay.portal.service.impl.CompanyLocalServiceImpl
public void updatePreferences(long companyId, UnicodeProperties properties)
throws PortalException, SystemException {
PortletPreferences preferences = PrefsPropsUtil.getPreferences(
companyId);
try {
String newLocales = properties.getProperty(PropsKeys.LOCALES);
if (newLocales != null) {
String oldLocales = preferences.getValue(
PropsKeys.LOCALES, StringPool.BLANK);
if (!Validator.equals(oldLocales, newLocales)) {
validateLocales(newLocales);
LanguageUtil.resetAvailableLocales(companyId);
}
}
...
}
protected void validateLocales(String locales) throws PortalException {
String[] localesArray = StringUtil.split(locales, StringPool.COMMA);
for (String locale : localesArray) {
if (!ArrayUtil.contains(PropsValues.LOCALES, locale)) {
throw new LocaleException();
}
}
}
you will see that "newLocales" are validate against
if (!ArrayUtil.contains(PropsValues.LOCALES, locale)) {
throw new LocaleException();
}
so if you add new locale key, in Display page of Portal settings, which is not in portal-ext.properties or portal.properties you'll get LocaleException.
Pay attention that oldLocales are read from preferences (database) String oldLocales = preferences.getValue(PropsKeys.LOCALES, StringPool.BLANK);
and validated against portal.properties/portal-ext.properties if (!ArrayUtil.contains(PropsValues.LOCALES, locale)) { ...
PropsValues.LOCALES => public static String[] LOCALES = PropsUtil.getArray(PropsKeys.LOCALES);
As stated in comment this behavior will happen if (and only if) you add new locale (in GUI) that is not in portal.properties
locales=ar_SA,eu_ES,bg_BG,ca_AD,ca_ES,zh_CN,zh_TW,hr_HR,cs_CZ,da_DK,nl_NL,nl_BE,en_US,en_GB,et_EE,fi_FI,fr_FR,gl_ES,de_DE,el_GR,iw_IL,hi_IN,hu_HU,in_ID,it_IT,ja_JP,ko_KR,lo_LA,nb_NO,fa_IR,pl_PL,pt_BR,pt_PT,ro_RO,ru_RU,sr_RS,sr_RS_latin,sl_SI,sk_SK,es_ES,sv_SE,tr_TR,uk_UA,vi_VN
or if you modified locales in portal-ext.properties than if not in portal-ext.properties.
For example if you have in portal-ext.properties
locales=en_GB
you will not be able to add any other locale from GUI unles you first add new locale to portal-ext.properties AND then go to Display page of Portal settings and add it there again.
there might be a way based on how you organize your editors: The default language for web content is based on the current language (e.g. the default language) of the user. Typically german users might have their language set to german, in order to read the german content version, no?
Alternatively you'd have to customize Liferay (e.g. the webcontent editor) and manually set the default language based on some property in the current site - this might be stored as custom field aka expando. This way it will truly be based on the site that content is being created in, but this might conflict with the current user's expectation: What do they set their default language for when the editor doesn't honor this?
Still - in your case the expectation might even be what you describe, so it's a valid option.
Is this level of detail enough?
I'm building a WebWorks version of an Android app that's localised into 39 languages.
At the moment all the localisations are in xml files of key-value pairs, one file per language .
Each language file has about 400 lines (roughly 40k per file).
Users can change the language used in app.
What options are there in WebWorks to solve this kind of situation?
I'd be more than happy to convert the resource files into any other kind of format to make working with it a better experience on the platform.
You could store each language set in a JavaScript file that you include/load as needed. (I've converted the XML data to a "Map" since it is just key/value pairs)
e.g. (just ignore my translations... I just Googled this, I'm by no means fluent in Spanish)
//Spanish File "lang_spanish.js"
var translations = {
"lose_a_turn": "pierde un turno",
"do_not_pass_go": "huele como un camello",
"take_a_card": "tener una tarjeta de",
"you_win_the_game":"sin motocicletas en la biblioteca",
"you_can_not_move":"desbordamiento de la pila puede ser un lugar divertido"
};
In your <head> you can then have a generic script tag, that you just change the source of as needed.
e.g.
<script id="langFile" src="js/lang_english.js"></script>
When you want a different language, just remove this script from the DOM and add your new one. e.g.
function switchLang(langName){
var headTag = document.getElementsByTagName('head')[0];
var scriptFile = document.getElementById('langFile');
headTag.removeChild(scriptFile);
var newScript = document.createElement('script');
newScript.id = 'langFile';
newScript.src = 'js/lang_' + langName + '.js';
headTag.appendChild(newScript);
}
//call with:
switchLang('spanish');
The alternative would be to load all 39 languages by default... but that seems like overkill considering most will only ever want 1 or 2.