I'm having trouble reading a NSLocalizedString through my English .csv file.
In my app a user comes across a UITableViewController and selects a row. Whatever that row's title is is set to a global NSString selectedRow inside a NSObject (this NSObject is imported in every class). Once this occurs the next UIViewController reads selectedRow, runs through the .csv file until it comes across it, and then vomits all the information needed onto the UIViewController.
Example: selectedRow = "About"; so in French this would be selectedRow = "Environ";
Now I don't have "Environ" in my .csv file, I have "About", so how would I force a NSLocalizedString to be English for a few moments without having to make a completely new French version of my .csv file?
If you want to use NSLocalizedString then you would need to make .string files, if your CSV is actually static and want to translate words like "About" then you can follow the instructions here to add the .string files, make one for English, one for French, then if the user is using French as the Language Setting, they will see the content in French... If your .csv is not static and it constantly changes and has full sentences, then this probably wont work, and you would probably want to use a french version of the .csv file... You can localize it as described above too..
Hope this helps
Daniel
Related
I have an app that is used to track/manage livestock. It currently supports one species, Sheep. We want to begin supporting multiple different species, like Goats, and Cattle. My first thought was to create something similar to NSLocalizedString(text, comment) like SpeciesString(text, species, comment) which would take the English string and the species name and translate the Sheep term Ram to the Cattle term Bull. And internal to that, I could use NSLocalizedString() to then further translate that to the proper language so that in the future I could support multiple languages as well.
I see that I can pass a tableName to NSLocalizedString() so that it will use a different file other than Localizeable.strings and that would allow me to programmatically pull values from a Spanish language file that is focused on Cattle instead of Sheep (something like Localizeable-sheep.strings and Localizeable-cattle.strings), but that won't help me with all of the text that is in the storyboard.
I know that there is built-in support for localization with the storyboard, but the problem I'm having is that when the text comes to my code, for example in viewDidLoad, it will already have been translated to the other language, for example Spanish. I would prefer to find a way to make the text in my views already have the right Language+Species combination by the time it gets to my code. But even if I did rely on programmatically swapping out the strings to use the right Species, the English will already been changed to Spanish and I'll get Carnero instead of Ram and if I try to pass that through to my SpeciesString() it won't match my underlying data, because my underlying data is keying off of the English version of the text.
Is there a way to create a custom language? I've seen this code that is used to change the localization language on the fly, and it works for swapping between en and es, but I can't create my own fake languages like en-sheep and es-sheep.
Is there either:
a) a way to create my own custom language so that the localization system will just pick my correct Language+Species combination?
or
b) a way to tell the Storyboard which table name/filename to pull strings from? So that instead of just having a strings file for my Main.storyboard be called es.lproj/Main.strings but I could instead have
es.lproj/Main-sheep.strings and es.lproj/Main-cattle.strings?
I think my inability to get my "custom language" to work was just an accidental oversight. I created an es-sheep.lproj/Main.strings and used the other SO post to programmatically set my language to es-sheep and it didn't seem to work...
... but it turned out that I had created those directories and files, but forgotten to add them to the project. Once I manually added them to the project, it started working and I was able to use my custom localizations.
I am currently working on an iOS app and localizing it into multiple languages but have faced an annoying (not breaking) issue.
When i would add a new localization for my storyboard xcode will automatically populate the strings, which is very nice. The issue i am having is that i have multiple interfaces which both have a back button. The text on these is of course the same and their translations are as well.
The question i was wondering about, is it possible, without using strings.localizable, to somehow merge multiple object translations into one?
This is how it would currently look:
"Pnu-Ec-HAj.normalTitle" = "Back";
"Rtx-fT-rdc.normalTitle" = "Back";
But it would be way easier if there was a syntax such as
"Pnu-Ec-HAj.normalTitle", "Rtx-fT-rdc.normalTitle" = "Back";
(this syntax is not correct obviously)
I have looked around quite a while but have not found any answers to this question yet.
Thanks for reading.
I'd recommend referencing every text in your storyboard in code, and setting the text on viewDidLoad like, e.g.:
buyButton.titleLabel.text = NSLocalizedString(#"SHOP_BUY_BUTTON_TEXT",#"Button for buying product in detail view");
It's loads of work if you have huge storyboards, but in the end you have a clean Localizable.strings with concise keys and comments, providing necessary context for your translators.
I prefix the key with the section of the app, so for example SHOP_***, USER_SETTINGS_***, etc.
In addition, we use a service like OneSky to organize our translations online and update them from the cloud (not affiliated with them, and it's not without its teething problems either).
Unfortunately the .strings files are key-value files and, by nature, there must be a key (that is composed by the nib ID of the element followed by the property) and the associated string value.
As Apple describes in the precedent link:
The standard strings file format consists of one or more key-value pairs along with optional comments. The key and value in a given pair are strings of text enclosed in double quotation marks and separated by an equal sign.
then, your idea is not supported by the .strings files.
The only way to support that feature is by using the NSLocalizedString in code.
With the iPhone 6s, Apple has introduced a new feature called "3D Touch". App developers are able to use this technology by using it within their apps or provide so-called UIApplicationShortcutItems on the home screen which appear when you 3D Touch the corresponding app icon. I've seen quite a few people out there who wanted to know how you would be able to localize those. Here's how.
What you have to do is, if you haven't already, create a new strings file called InfoPlist.strings, then you localize this strings file to the languages you wish via the File Inspector on the right.
Now, you write down a key (for example: ADD_ITEM_SHORTCUT_TITLE or ADD_ITEM_SHORTCUT_DESCRIPTION) and the correct translation for each localized file. For example:
English file:
ADD_ITEM_SHORTCUT_TITLE = "Add";
ADD_ITEM_SHORTCUT_DESCRIPTION = "a new item";
German file:
ADD_ITEM_SHORTCUT_TITLE = "Füge hinzu";
ADD_ITEM_SHORTCUT_DESCRIPTION = "ein neues Item";
Then, go to your Info.plist and enter your key to the corresponding field. For example:
That way, you get localized UIApplicationShortcutItems. Now, they look like this:
Phone language English:
Phone language German:
Here's the scenario. I have a set of settings in an app. For example consider my app as a video player. So there are settings like allow full screen, display subtitles etc. All these settings have boolean values since you either turn on or off them.
These settings should display inside the app in a table view. And if any of them are activated or when the user taps on them to activate/deactivate, you show it by setting the checkmark accessory view of that cell.
Since I need the settings to be displayed this way and only within the app, I cannot simply use Settings bundles. There's also another catch. I need these settings to be localized.
What I initially thought was to have separate plists for the languages I support.
Settings_en.plist (English)
Settings_sv.plist (Swedish)
Then fetch the plist name depending on the system language and display its values.
let filePath = NSBundle.mainBundle().bundlePath.stringByAppendingPathComponent(NSLocalizedString("SETTINGS_PLIST", comment: ""))
But this is not ideal because say I'm running in Swedish and I change the Subtitles setting to on. Now i have to update this in both plists. This will quickly become even messier if I add more languages in the future.
Is there a better way to store settings which is easier to save and fetch and also supports localization?
I was able to find an answer elsewhere. Here are the steps taken to resolve this issue.
Instead of multiple plists, create one plist and have the keys in English language.
Then have the localized strings in your string files with the same English keys.
Localizable.strings (English)
FULL_SCREEN = "Full Screen";
SUBTITLES = "Subtitles";
Localizable.strings (Swedish)
FULL_SCREEN = "Helskärm";
SUBTITLES = "Undertexter";
In the code when you're displaying the values in a table view, refer to them by that key.
let setting = settings[indexPath.row] as [String: Bool]
let title = setting.keys.first
cell.textLabel?.text = NSLocalizedString(title!, comment: "")
I try to make my App as simple as possible. For this i want to store a .txt file with names on a Server and then populate a TableView with this txt. Inside the txt there should be just names, one at each line. Is it possible to get this txt into a tableview? I would use a plist file but the app will be updated by a person which is not used to programming and plist files.
Thanks for every answer.
You can read a simple textfile in whole into a NSString, split it by the linefeeds into a NSArray and there is your datasource for the tableview. You could make it editable with NSMutableArray instead, later convert it to NSString again and write it back to a file.