I have this project localized in several languages. Xcode shows the following list of files:
You can see that some languages have more files than others. Is there a way to list what files are missing on each language?
Yes, I know that I can use the parameter -NSShowNonLocalizedStrings YES as an argument passed on launch. I did that but that is not showing anything.
This is an indirect answer to your question; If you have that many .strings files you might want to organise them more structurally.
You could put all translatable strings in either a database or a spreadsheet and generate your source files from there. This may sound like more work but I think in the end it saves time.
See this other question about consolidating strings files. Or see my example spreadsheet to manage your localisations and spot missing texts more easily.
Related
We have a project with multiple Languages enabled, so each language has its own Localizable.strings file. During development we are constantly creating more strings (in english) adding them at the end of our Localizable.strings (base) ,and until the translation is done, also we add them to the other Localizable files. We have around 3000 Strings so the
ISSUE: For one languages we got the strings translated, by only a bunch of them, so there are like 60% of keys and translations missing. So we have to merge, somehow, with the Base file to include the missing KEYS and Strings, as our KEYS are kind of non readable like this: APP_SETTINGS_MENU_ITEM_SCREEN_ALWAYS_ON so we don't display the missing KEYS but its English translation.
QUESTION: Is there a better way to do this? a way to organize the strings, and make sure that all Localizable.strings have all KEYS and we can export & import the missing strings for translation?
I have good experience with Crowdin, it works really well with collaboration and defining multiple projects.
Cheaper alternative is to do the management in spreadsheets: https://github.com/xavierha/localize-with-spreadsheet
I've picked up an iOS project that was previously localized for 20 languages, but not yet translated. While reviewing before submitting for translation, I discovered that most of the NIBs and storyboards that are localized have generated strings for a lot of placeholder text that is not used runtime. Since many of the files are only placeholder text strings, the localization just needs to be removed. I'm aware that this can be done by removing the individual language localizations, deleting the reference to the file in the project, moving the file up a directory from Base.lproj, and re-adding it. However, since there are 20 languages and 40+ resource files, removing the localization in this manner is relatively tedious and time-consuming.
Obviously I can just fix it as mentioned above, but I would love to avoid the tedium in the future. Does anyone know of a better way to un-localize a resource file? If not in Xcode, a command line solution would be equally appreciated; anything that doesn't require thousands of repetitive mouse clicks.
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.
I appreciate your help in advance. I have searched high and low for an answer with no luck.
I have an app that uses very specialized sports terms which I store in a plist file. Those terms are then displayed in a UITableView. When the user taps on the skill, a video demo is played. The app works great, but I would very much like to localize it for other languages.
I have gotten the terms translated, and I was hoping I could localize the plist file by making a copy of it and just changing the sport-specific terms in each successive copy of the file, and then put it in its respective language folder. Is this possible and if so, can someone please point me to a good example or tutorial?
So far, I have I have tried to localize the plist file for Russian in Xcode and put it in its own ru.lproj folder, however, then when I run it in the simulator no data appears at all in the UITableView! Without the Russian file, it works fine. So my thought is that somehow Xcode is confusing the plist file because the name is the same, even though it is in a different directory (en.lproj and ru.lproj). The file is called Basic.plist in both directories. This process is totally confusing to me, and from what I gather it shouldn't be that difficult to figure out!
Again, thank you in advance. The localization concept is completely new to me and I am eager to learn it. I am quite sure I understand how the .strings files work with strings that are embedded in code, but I would like to know if it is possible to translate an entire pList file.
A lot of things could be wrong. One possibility is that the plist files don't get copied into the bundle (verify in your target's Build Phases page--it should say Basic.plist with "...in (localization).lproj" written next to it.
If you have manually created the ru.lproj, maybe you copied it in the wrong place, or left the original file in the wrong place (it should now be inside en.lproj). Rather than manually create the file, it's easiest to select the file Basic.plist in XCode and use the Localization control inside File Inspector to add localizations. As Kevin Grant mentions, if this doesn't show your file as having English and Russian, then something is wrong, and you could start again using the + control.
Finally, I'm not 100% sure about this but close enough: I believe your code probably needs to be updated to figure out where to load the plist file from. It it were a .xib or a .strings file, you wouldn't have to do this as this would be automatic and iOS knows to look inside the relevant .lproj folder first (when you load a .xib you only specify its name, not its exact location). But I assume you are loading the plist file through a specific path, therefore the path must now include the .proj folder.
If possible for you, I think a nicer approach to having different plist files per language would be to have just one plist, but instead of displaying the string from the plist you could use it as a key to your .strings file. You can retrieve the localization using the NSLocalizedString macro (which is defined as [[NSBundle mainBundle] localizedStringForKey:(key) value:#"" table:nil]) which will give you the corresponding value in the localized .strings file at run time. Of course this would mean that when you update your plist, you would also have to update your .strings files to match. The good thing is that you wouldn't need to determine the path of the plist for your active language -- with NSLocalizedString, you don't provide a path at all.
Is there any other way to localize iPhone apps beside the use of Localizable.strings? Can I use Google Translate or something like that?
I have my application written in English, and I have created Localizable.strings files for about twenty languages. I have the English Localizable.strings working perfectly, and I have tried Italian as well. Is there any way to translate these Localizable.strings to the rest of the languages automatically?
I mean is there any program or something to do the job for me?
In short: No, there is no program for that. It's the same problem as translating any text: You need to understand the meaning to give useful translations.
As a quick fix, you can of course simply take the strings in your Localizable.strings file and copy them into a Spreadsheet, then run one column through Google Translate and copy the result back. Then reverse the procedure and you have a translated Localizable.strings. A regex for doing this would be:
^"(.*)"\s*=\s*"(.*)";$
that works fine in eg. TextWranger with grep mode on, then you can replace the text with
\1\t\2
to create a the tab-delimited file from a strings file.
I still suggest you invest in a native speaker of each language to double-check the translations, or your app will become a laughing stock. Google Translate just can't replace a real human yet...
To localize your app you can use Localizable.strings or use localized XIB.
I don't use the second approach because it is more cumbersome to manage.
With Localizable.strings you have to code a little bit more but I prefere it.
To translate I think you can use google translate (I do that) and build the file for each language.
If you want to use an online translator, remember that it can be not always available and your user must be connected all the time.
So my advice is to build all the language files since they are managed by the OS and you will have a more reliable solution.
You should create Localizable.strings for each language and translate them with any translation tool