When we create a group or folder in Xcode, must we name the group or folder in English?
I heard about all the people saying yes, but my master told me that we can use Chinese (another language) name groups or folder, too. So now I am a little confused about this. Is there any hidden danger when we use Chinese? Could anyone tell me the truth and the reason?
No, in past I've builded a project entirely in italian without any problem, and I'm speaking about Xcode 5.
However you can find official documents here
And you can find also the support to Right-to-Left and Left-to-Right language here.
P.S. If you want to change entirely language to add some charset, look the Apple official instruction to do it here
Related
I would like to relase two versions of the same appliaction in different languages. (to be clear - I don't want to release just one app with option to change language but two apps, each one in different language).
The process of app localizationing is described for instance in this tutorial http://www.appcoda.com/ios-programming-tutorial-localization-apps/ but it creates one app with option to change languages.
My question is - is it possible following this method to build (archive) an application in just one language, and then the second one in another?
If not please advise me what would be the best method to do so?
Two exactly the same but separate applications imho - not the best choice!
it means two source code projects, right, with localized separate xibs, stories etc?!
You know why?! Simply because it's difficult to support.
If you need to fix something -> welcome to fix in both projects etc...
You should follow the tutorial and create localized application for two different languages.
I'm assuming to submit both versions to appStore you need to:
When submitting:
set different languages as a default
replace bundle identifier smtl like
com.yourCompany.yourAppName_english/spanish
so you can submit the same application but with different default language.
This is just theoretical... hope it helps
One Language App = No Localization = No need to follow the tutorial
(you just build the app with all NSString with one language)
Your Localized App support more than one language will need to follow the tutorial
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.
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 have been using Google's Translation web site to translate my localizable.strings file to multiple languages, but it is very tedious.
Does anyone know if there is a better way to do this?
Don't do that! Most people will prefer a non-localized English version to a poorly translated one.
Either contact a localization service (they will translate the .strings files directly) or don't localize your app.
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