I'm attempting to add localizations to values that appear in my Info.plist file. I'm having no trouble doing this for top-level keys using an InfoPlist.strings file. But, I cannot figure out how to get it to work for non-top-level values.
For example, the CFBundleDocumentTypes is an array of dictionaries. I need to localize each array's CFBundleTypeName key differently. A similar situation exists for UTExportedTypeDeclarations/UTImportedTypeDeclarations, with the UTTypeDescription key.
Apple's documentation on UTTypeDescription specifically says that it can be localized with an InfoPlist.strings files. And I've tried, but have not been successful.
As reference, I tried to refer to Apple's own apps. The only one I was able to find that uses any non-root keys was Xcode, and Xcode isn't actually localized to anything other than English. I cannot be sure if its approach actually works. And, there's at least some strangeness within Xcode's bundle, because there are keys that appear in its InfoPlist.strings file that aren't actually in the Info.plist itself.
Does anyone know how (or if) this can be done?
Real life example with my own app. If you have an exported type with this:
<key>UTTypeDescription</key>
<string>CreaPhoto document</string>
My French translation in InfoPlist.strings is:
"CreaPhoto document" = "Document CréaPhoto";
It seems so dumb a "duh yeah of course" moment, but this is totally different from everything else in the info.plist translations, where you are expected to put the key when it's in root. No donut to Apple for not explaining this in their page.
Things to add in macOS: you must increment your Bundle ID each time you modify this (38 to 39 to 40 to 41 to 42 ...), you must build your new version, execute it in debugger (or release), and you must logout and logon so it gets taken into account.
There are ways with less steps, but this is the safest sure-fire way I found to get it applied in Finder.
Related
TLDR: Xcode generated storyboards for each language, however I want the "old"(?) *.strings files. How?
I am currently in the process of localising my storyboards. After I enabled everything, Xcode generated another storyboard alongside the original (english) one for me to localise. I was surprised, I expected a Localizable.strings file, like the apple documentation still states as of April 3, 2021:
For storyboard and XIB interfaces, select the user interface files (files with a .storyboard or .xib filename extension). Xcode adds a strings file to the localization folder that contains the text to translate, as well as comments that describe the user interface components. For example, if you add German to an iOS app that uses storyboards, LaunchScreen.storyboard becomes a group containing a LaunchScreen.storyboard (Base) and LaunchScreen.strings (German) file.
I searched around the internet, in apple developer forums, watched both WWDC18 and 19 talks about localisation in Xcode, but did not find a single mention of translated storyboards.
After the initial translation, which works great due to the simplicity of just filling everything in, it gets frustrating however, since every layout change needs to be repeated for every language. This can't be intended, there must be a better way, right? Sadly, I didn't find anything. Even a hint to a piece of documentation regarding these storyboard copies would be greatly appreciated. Thanks!
There are some screenshots of the possibility to convert these two formats via a dropdown, like the third picture in this post. However for me, there is no dropdown next to the language item when I click the storyboard, neither on the group, nor individual base or localised ones:
Is this a bug or am I missing something here? I am using macOS Big Sur 11.2.3 with Xcode 12.4 (12D4e).
Turns out, you need to use the Base Localization feature, the dropdown then appears and you can convert existing storyboards to *.strings files.
Please help me out with this issue while uploading application to Appstore I am getting this error:
I experienced similar issue recently - messed with a lot of different things but at the end, the issue was a bad character in the file - which is only visible through an editor like vi. Open the file with vi and then navigate to the bad character if you find one (it usually sticks out like a sore thumb as a different color to the rest of the file) - then hit 'x' to delete it. The type colon on keyboard and 'wq' and hit enter to save and exit. Delete previous archive - archive again and try to validate. This worked for me.
I had the same issue & I wasted full day looking here and there creating builds and validating them.
I checked my Info.plist file & there was no control character.
One property CFBundleShortVersionString from Info.plist was referring to $(MARKETING_VERSION) which had the control character. So kindly check the Info.plist file first and then the referencing variables.
I work in a company that has an app in production with a localization bug in iOS 9 only. The app shows the key of the localized strings, not the values. Apparently, it can't found the corresponding string in the table. On iOS 8, the app works fine.
I don't know the source code well, but I made sure the file Localization.strings is there, in the right bundle, with the correct target. I'm pretty confident the resource is there, because of tests I made and mostly because the strings are there in iOS 8!
I looked for changes in APIs in iOS 9 but couldn't find anything related to my issue. I also ran the plutil command on all the .strings files and I got OK for all of them.
Any clue as to where to look?
It turns out the app was using multiple Localization.strings file for specific localizations (tweaking the bundle and Localization system). Deleting all those files (with duplicated names) and replacing it with another system (a plist file, mainly) made it work correctly.
It seems obvious there was a conflicting name issue here, but I'm still puzzled by the fact that it worked with older iOS (8 and under).
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.