Specify base localization for Localized formatted APNS strings - ios

My base localizations are in storyboards, but also in a struct like this:
struct Strings {
struct Restaurant {
static let makeCall = NSLocalizedString("Restaurant-makeCall", value: "Call %#", comment: "Restaurant-makeCall: title for button that allows you to call a place")
}
//...many more
}
This works pretty well because it keeps them in one place, defines a key that is separate from the base translation value, and gives me autocomplete when I'm using them: Strings.Restaurant.makeCall
To enter translations, I use the xliff import/export process: editor > export for localization. I found genstrings had trouble with the longhand form of NSLocalizedString.
This all works well until I get to Localized APNS Messages. Given an loc-key and optional loc-args, They search for a matching localization key.
For the translations, this works, because there's a Localizable.strings built for each translation when I import the translated xliff file.
There is no Localizable.strings file for my base translation. I attempted to make one, but the xliff export does not notice those fields to add to other translations, so I think that's not the right way to do it.
How do I add base translations in a way that will work for APNS?

One functional, but duplicative approach is to define them in both places:
Define keys (and unused values) in the Strings struct. The xliff export notices these and this allows other languages to provide translations
Define keys and values in a Localizable.strings file you create for your base translation. This allows APNS to find the values when you're in the base language, but xliff export can't see these.
This works, but if somebody ever changes one without keeping the other file up-to-date, differences in translation will occur that will be hard to detect, so I don't like it very much.

Related

XLIFF doesn't contain all forms of plurals when trying to localize a project in Xcode

I'm trying to localize a small Xcode project (Xcode 9 and Swift 4). In that project there are places where I use plurals, so I need to localize them, too. To do that, I use stringsdictfile. In code I use localizedStringWithFormat(_:,fromat,:argument) static method on a String. Here how my code for a plural looks (I just print the words for testing):
let localizedString = NSLocalizedString("%d apple(s)", comment: "The number of apples")
print(String.localizedStringWithFormat(localizedString, 0))
print (String.localizedStringWithFormat(localizedString, 1))
print(String.localizedStringWithFormat(localizedString, 2))
print(String.localizedStringWithFormat(localizedString, 10))
Then I create a stringsdict file. It looks like this:
In the video from WWDC 2017 (session 401) about Localization it is said, that when we use stringsdict file for localizing plurals into other languages (in this case, I want to localize it into Russian) we just need to give values for the cases of our development language (English), and when exporting for localization, Xcode will automatically create cases in an XLIFF file for the language into which we want to localize. So I've given values for zero, one and other (in the demo from the session values are given only to keys one and other, however, I don't thing that that's the reason of the problem).
Now, when I create an XLIFF file it looks like this (only the part of apples):
As you can see, Xcode doesn't generate cases for a particular language automatically (for Russian it should have 4). I'm using stringsdict files as well as trying to localize plurals for the first time, so I can't figure out what I'm doing wrong. If you know where is the issue, or have any suggestions, I would appreciate your help.
There is little you can do in Xcode. XLIFF just holds the segments that it's been told to hold.
A better approach would be to rephrase the strings so that plurals are less an issue, like:
not "%d apple(s)"
but "number of apples: %d"
You should file a bug at apple about that.
Unless you have a requirement to work with the XLIFF from Xcode, I suggest you don't and instead rely on the string files.

NSLocalizedString in Spritekit SKLabelNode

I've been searching all over the internet and there doesn't seem to be a clear explanation on how to localize strings using SpriteKit. Only seeing tutorials for people using the interface builder, but all I really want is, imagine this:
I have an SKLabelNode called label. And I define the text like:
labl.text = NSLocalizedString("titleOfTheScreen",nil)
So basically what I think I have to do is add the new language in the Project settings. Then, I add a new Strings file called Localized, and add it to the new folder.
But what happens to my English language? There's no file for the original one
First you have to add a Strings File:
Then open the project settings and add a new language:
Mark your added strings file as target:
Find the newly added localising file. (English is automatically added)
From your screenshots I can see that you have "File.strings" file. You should have created "Localizable.strings" file.
Also, I can see that you have the (Base), (English) and (German) strings version. Why do you think English is not there?
In each of the files you should put strings like that:
"titleOfTheScreen" = "blah-blah";
Replace "blah-blah" with the proper translation in each of the strings files. It's important to note that the semi-colon at the end of the lines in strings files are mandatory, otherwise Xcode would issue some really funny error messages. This is easy to overlook if you're programming in Swift and trailing semi-colons are not mandatory.

Xcode Localization: Keep translation in sync with Storyboard

Here's our localization workflow:
Build stuff in interface builder
Export project for localization
Translator looks at xliff files and applies translations for new strings (Only new untranslated strings)
Import xliff into project
This works fine for building new stuff. But if the developer changes the text in a label in storyboard that has already been translated, he will have to remember to delete the translation for that label, so the translater sees that string as untranslated. If the developer forgets to delete that translation, the translation will be wrong, which is a very hard error to find.
When code is localized like this:
var testString = NSLocalizedString("Some text in english", comment: "just a test string")
The string ("Some text in english") defines the key in the xliff-file, which means that if the string is changed, then the exported xliff file will automatically have a new string that needs to be translated.
I've tried to solve the problem with xcode's "export for localization..." function, with genstrings, and with BartyCrounch, but all methods seems to use the UI Element's Object ID as a key for the .strings-files. Which means it won't react to changes in the actual string.
The only solution I've found so far, is to set every string that need translation in the storyboards in code via a IBOutlet, but this is a quite comprehensive solution.
Do you know any tools or methods that solve this problem?
I tried what you said and understood what you meant. I think the solution is straightforward.
First, I added a new button in storyboard, named it "Test". Then I translated it in Chinese, imported the translation. Changed "Test" to "GoGo" and exported the translation again. The xliff part was changed from
<trans-unit id="jso-qF-Z1t.title">
<source>Test</source>
<target>测试</target>
<note>Class = "NSButtonCell"; title = "Test"; ObjectID = "jso-qF-Z1t";</note>
</trans-unit>
to
<trans-unit id="jso-qF-Z1t.title">
<source>GoGo</source>
<target>测试</target>
<note>Class = "NSButtonCell"; title = "GoGo"; ObjectID = "jso-qF-Z1t";</note>
</trans-unit>
What to do next
I don't know if there is a ready-tool for this. But you can use Git as it can always find the diffs.
Steps:
add you translation folder to git
commit current files
export new translations from Xcode
look at diffs with git
As you can see in the picture, git already shows what changes, that is where you should translate again.

Best way to utilize strings in iOS

I am new to coding in Objective-C, but am coming from the Java world of mobile development. In Android, we use a strings resource, and then point to those in the Java class. Is there an analogous process in iOS that we should be using, or do we "hard-code" the strings into the implementation files? I haven't yet found a good tutorial using the localizable string (and .strings) file.
You can use the NSLocalizedString macro from Foundation to retrieve a localized string. Read here:
http://www.icanlocalize.com/site/tutorials/iphone-applications-localization-guide/
Example: build a bilingual (English-French) app.
Whenever you encounter a string to be displayed to the user, use NSLocalizedString instead of the actual string constant. For example:
instead
self.title = #"Welcome";
use
self.title = NSLocalizedString(#"Welcome");
Create two directories inside your app bundle as follows:
MyApp.app
English.lproj
Localizable.strings
French.lproj
Localizable.strings
In the first Localizable.strings file you can write key-value pairs like this:
"Welcome" = "Welcome";
In the second one:
"Welcome" = "Bienvenus";
When you add these files and folders to your application, an recompile it using the NSLocalizedString macro, you'll be able to use your app in French also when the system language is French.
Sure, there's a way to do that.
Take a look at the Apple doc here - http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/Strings/Strings.html
There's not much more to it than that really. Although I tend to just hard code a lot of strings but it's definitely worth taking the time to learn about string resources because it's the basis of internationalisation.

Localizing strings from the Settings.bundle using InAppSettingsKit

I am attempting to use InAppSettingsKit to manage my settings. This uses the Settings.bundle with a .plist file and the .strings files for each of the languages being translated.
I can confirm that the translation of my strings is working properly outside of my application, using the Setting application. But when I am in my application, the translation is not occurring.
I think it comes down to code like this, from the InAppSettingsKit class IASKSettingsReader, with a couple logging statements that I thought my be helpful:
- (NSString*)titleForStringId:(NSString*)stringId {
NSLog(#"%#",[_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable]);
NSLog(#"%#",[_bundle localizedInfoDictionary]);
return [_bundle localizedStringForKey:stringId value:stringId table:self.localizationTable];
}
If I understand correctly, this should be using a table with the name self.localizationTable as the source of the translation. This value is simply "Root". It's not a path to the Root.strings file in the selected language, so I am guessing that the method localizedStringForKey:value:table: must be using some global system reference that points to the correct path.
I have confirmed that the strings file name is "Root.strings" all around, with a capital R, including in the Root.plist file.
[_bundle localizedInfoDictionary] returns (null); It is doing this for two language settings of English and French.
I'm not sure how to debug this. Thanks for any help you can give.
I'm using InAppSettingsKit with localized text with no problems. Two things I can think of that you could check: are your Root.strings files located in the correct subdirectories of Settings.bundle (en.lproj and fr.lproj for English and French?
Is there a "Strings Filename" entry in your Root.plist? It should simply contain a string with value "Root"
It has been quite some time since I resolved this, and at the time, I didn't fully understand it. But, in the interest of closing out this question, I'll point to the following documentation for future reference:
NSBundle Class Reference
which refers to the following:
Resource Programming Guide
In the second document, refer to the section "String REsources -> Loading String Resources Into Your Code"
The solution contains a properly configured Root.strings file, which shows up in the file list like this:

Resources