How to make a JSON file localizable in iOS? - ios

I have a JSON file containing a dictionary with strings in an iOS app. Our dev team sends off our app to a localization team via an .xliff file. Is JSON compatible with localization in iOS? Or should I convert it to some other file type?

I would suggest using the Apple-provided file type of .strings
Localization in iOS is actually really great. You have a .lproj folder for each language that you are using, prefixed by the ISO 639-1 language codes.
Within each of those folders, you can provide a .strings file that would contain all of the localized strings for that language.
For example, your en.lproj could have a "Localizable.strings" file as follows:
"Hello" = "Hello";
"World = "World";
And your es.lproj (Spanish) could have a "Localizable.strings" file as follows:
"Hello" = "Hola";
"World" = "Mundo";
You would then start using NSLocalizedString for all of your user-facing strings throughout your app. It might take a bit of leg-work to get started, but it is a very helpful system that is already built-in. Take a look at NSHipster's NSLocalized String entry for a good read about how this works and how it might benefit you.
Links valid as of July 30, 2015

Related

Translate XLIFF file into specific language xcode

I'm doing localization in my IOS App,My xcode has created xliff file from export for localization and I have multiple file like this...
as content of es.xliff is like this..
</header>
<body>
<trans-unit id="1A8-nz-WtR.placeholder">
<source>E-mail*</source>
<target>E-mail*</target>
<note>Class = "UITextField"; placeholder = "E-mail*"; ObjectID = "1A8-nz-WtR";</note>
</trans-unit>
<trans-unit id="1gB-DL-EAz.title">
<source>Add Location</source>
<target>Add Location</target>
<note>Class = "UINavigationItem"; title = "Add Location"; ObjectID = "1gB-DL-EAz";</note>
I want to translate it in spanish which software will do that or is there any way.I had browsed but no success.
You will need a XLIFF Editor - check out http://xliff.brightec.co.uk/ - it's online, it's free and does the job.
You'll still need to manually translate each entry.
I prefer to export XLIFF to Word (docx format), send Word document to translator on Fiverr a then import translations back from Word document to XLIFF file. https://129bit.com/home/xliff-to-word-and-back
I found a workflow that works really well. I downloaded Swordfish and signed up for their free trial. Swordfish is an XLIFF importer, editor, and exporter. Swordfish also works with machine translation engines like Google, DeepL (which I have read offers superior translation capabilities compared to Google - YMMV), Microsoft Azure, and others. I signed up with DeepL and got their API key as part of their one month free trial. I imported the API key into Swordfish. I was then able to use XLIFF files that I exported from XCode, import them into Swordfish, do the machine translate, verify the translations, then export the file. I then went to XCode and imported the updated file.

Xcode localization - how to create localized strings for development language

Using Xcode 7's localization export workflow, I can export to Xliff, which can be provided to translators, who will give back a translated version, which we import again.
However, how do I generate one for the original development language?
I want to do this so that I don't have to maintain my development language strings files manually by hand.
Here is the scenario:
I start with no strings file in my project, just Swift code which uses the NSLocalizedString
static let something = NSLocalizedString("something.hello", tableName: "MyStuff", value: "Hello world!", comment: "some comment")
From the project settings, I choose Editor -> Export for Localization. Because I have no existing strings files, when I export, there are no options. Just a "save as" prompt.
This will perform an Xliff export from the original source code. (Same as when you choose "Include: Development Language only" from the prompt when other localizations already present). The Xliff looks like this, with only <source> tags, and no <target> tags.
<trans-unit id="something.hello">
<source>"Hello world!</source>
<note>some comment</note>
</trans-unit>
The Xliff file is modified by translators, and translated to simplified chinese
The translated Xliff file is re-imported into project via Xcode
This creates the MyStuff.strings file for simplified chinese
Problem - when I run the app, the app will use the chinese strings file, even when language is english, because an english file doesn't exist. It doesn't seem to use the default value anymore. This means I need an english strings file too.
How can I generate an english (the development language) version of the strings files through the import/export process? Xcode doesn't let me "export" in the original development language. So I can't re-import it to create the strings files.
Note on genstrings
In the documentation for Separating User-Facing Text from Your Code, it says "Alternatively, you can generate the development language strings files from NSLocalizedString macros directly, as described in Creating Strings Files for User-Facing Text in Your Code." , which tells you to use genstrings
However that genstrings no longer works for Swift when you specify the tableName.
It's my understanding from what I've seen on SO that multiple radars have been filed, but it seems Apple is no longer supporting it.
I've worked out the problem.
It's doesn't seem necessary to generate strings files in the development language. This must be why the capability doesn't exist in Xcode.
My problem was that the app didn't think that my development language (english) was supported, so it did further fallback, and ended up picking a language that my app was localized for (in this case, chinese).
By adding a file localized for english, and ensuring there is an en.lproj folder in the bundle, it infers my app is localized for english, and will correctly use the default values specified in the NSLocalizedString calls.
This means I don't need a seperate copy of the english strings files. Which is great, because I won't need to keep that up to date as the app changes. The source of truth is the Swift source code only.
This link was helpful:
How does iOS determine the language for my app

iOS- How to translate english (.string file) language in different languages at a time?

I am facing a problem. I am working on an app which is supported around 30 languages. I have tried google toolkit translate (https://translate.google.com/toolkit/ ) but it is not working properly. For example let assume in .string file I have 40 lines of codes. If I translate language using google toolkit then it converts just 4-7 lines sometimes 8-9 times and so on. Others all lines it skips. Please let me know how can we translate English language in multiple language (around 30) at a time. Please share Any tool name or site name. Thanks guys.
Here is a project which can convert your localization.strings file to any language using google translation api.
You just need to copy paste all the data of localization.string file into a txt file. and add that txt file in app bundle file and specify file name in Constants.h file. Also mention the google translator api key. You can also mail the translated file.
Localization using google transtion iOS Project Link

compare two .strings file for finding missing keywords

I have two .strings files in my application for supporting both persian and english language in my app.
For example I below files
en.strings:
"HELLO"="heloo";
"THANKS" = "thanks";
and another one
fa.strings:
"HELLO"="سلام";
Is there any tools in xcode that let me know that fa file do not contain THANKS keyword?
If you actually export and import localisation files, xCode will set them for you, as well as deleting the unused ones. No need for any tool.

Does my Base Internationalization storyboard have to correspond to a fallback language for all unlocalized languages and strings?

I've looked through some internationalization documentation and videos on apple developer, but I never found an explicit answer to that question. In Apple's tutorials I see the Base.lproj folder alongside en.lproj and zh.lproj -- the example translation (localization) is from English to Chinese. But they tell me that there's a file en.lproj/myStoryboard.strings, and that is confusing. I can't see the point in creating an English localization for the storyboard (that is already in English).
So my questions are if the user will ever see the strings in the Base.lproj/myStoryboard.storyboard?
Do the strings in that file have to be the default strings that are shown to the user if the system cannot find the user's preferred language folder in my bundle?
Can I explicitly say "never use Base.lproj/myStoryboard.storyboard, always fall back on en.lproj/myStoryboard.strings"?
In other words:
Let's say I want my app to display in English whenever the user's language isn't available, but that my Base.lproj/myStoryboard.storyboard is in Swedish. Do I then have to localize the Base Storyboard to sv.lproj/myStoryboard.strings and translate all strings in the Base storyboard to English to accomplish this?
In my case, XCode 5 didn't create a en.lproj/myStoryboard.strings, there's only the original storyboard in the Base.lproj folder. Maybe it's an old XCode issue?
Try to remove that file and see if your app gets along with Base.lproj for default, English strings.
Your Info.plist file should have an entry Localization native development region, which points to the lproj folder to be used in case the required string doesn't exist in the preferred language.
I'm not sure about this, but I think you have to use en and UI with a Base.lproj would automatically fallback to Base.lproj.
Does that help you in any way?
So my questions are if the user will ever see the strings in the Base.lproj/myStoryboard.storyboard?
It is the default to use those strings for the development region localization, which is typically English. If there was a matching strings file for english, it would supersede the strings in the storyboard. This is typically redundant, so it isn't normally used. If you really want all of your languages to be handled identically, you can do this.
Do the strings in that file have to be the default strings that are shown to the user if the system cannot find the user's preferred language folder in my bundle?
These are unrelated concepts. The strings embedded in the storyboard are equivalent to having ones in en.lproj. After that, language fallback works the same as without Base.lproj.
Can I explicitly say "never use Base.lproj/myStoryboard.storyboard, always fall back on en.lproj/myStoryboard.strings"?
If you have en.lproj/myStoryboard.strings, and english is the development language, they will always superseded the strings embedded in Base.lproj/myStoryboard.storyboard for English. Including when English isn't the preferred language, but ends up being chosen as the fallback language.

Resources