I have a client who I am pricing an app for, however other than the English version they would also like a Japanese version. Has anyone had experience in a similar case, is there an easy way to do it? Do I need to create two versions, one English and one Japanese? If it were two Latin languages I could imagine it would be easier but Japanese write from top to bottom, right to left so this worries me.
You don't seem to know a lot about Japanese. They're perfectly accustomed to western-style left-right, top-down writing, especially due to the influence of computers. You can of course create separate views (views only, no need for separate apps) for Japanese that switch everything to top-down, right-left writing. But it's only a minority of apps that do that. In fact, the Daijirin Japanese-Japanese dictionary is the only example I know of.
Talk to your client what kind of Japanese localization he wants. Odds are, he just wants strings replaced. See #kelloti's answer.
As a general advise: Make sure you get a native translator/developer who can guide you in a good localization. Don't simply copy-paste in strings you get from somebody else that you have no idea how to even read. This only produces terribly localized versions.
Read the Apple documentation on internationalization. I don't think you should have many issues with Japanese (how else would they sell phones in Japan?)
Related
I don't know if my approach to this is fundamentally wrong, but I'm struggling to get my head around a (seemingly trivial?!) localisation issue.
I want to display the title of a 'System' UITabBarItem (More, Favorites, Featured, etc...) in a navigation bar. But where do I get the string from? The strings file of the MainWindow.nib doesn't contain the string (I didn't expect it to) and reading the title of the TabBarItem returns nil, which is what stumped me.
I've been told, there's no way to achieve it and I'll just have to add my own localised string for the terms in question. But I simply don't (want to) believe that!! That's maybe easy enough in some languages, but looking up, say, "More" in already presents me with more than one possible word in some languages. I'm not happy about simply sending these words for translation either, because it still depends on the translator knowing exactly which term Apple uses. So am I missing something simple here? What do other people do?
Obviously, setting the system language on my test device and simply looking to see what titles the Tab Items have is another 'obvious' possibility. But I really have a problem with half baked workarounds like that. That'll work for most languages, but I'm really gonna have fun when it comes to Russian or Japanese.
I'm convinced there must be a more reliable way to do this. Surely there must be a .strings file somewhere in the SDK that has these strings defined?
Thanks in advance...
Rich
The simple and unfortunate answer is that aside from a very few standard elements (e.g. a Back button), you need to localize all strings yourself. Yes, UIKit has its own Localization.strings file but obviously that's outside of your app sandbox so you don't have access to it.
I filed a bug with Apple years ago about providing OS-level localization for common button titles, tab item labels, etc. That bug is still open but obviously they haven't done it yet (sorry, I don't have the radar # handy).
I am developing applications for mobile phones with different operating systems (Android, Symbian, iPhone). Applications are sold internationally so they need to be translated to different languages in addition to english version.
I assume most mobile developers do the translations using some paid external service each time. This approach does not look very cost-effective to me. Would it make sense to have a website where simple translations would be done using crowdsourcing (other developers)? Most strings in mobile applications are very simple and short, for example "OK, "Cancel", "Are you sure?", "Please enter your password". Also the same strings are used in hundreds of applications. Instead of paying for translating all strings, developers could save money by only buying their difficult application specific translations.
Does anyone agree with this idea? I have seen many opensource projects doing the translations succesfully using volunteers.
I just found solution for me. Many users find this question in Google so I think my post must be helpful:
This is solution for us: crowdin.com - agile localization solution for tech companies
Microsoft allows you to view their terminology database: https://www.microsoft.com/Language/en-US/Default.aspx
That covers about 90 languages and will get you the things you mention such as common button captions, etc.
The problem you are facing after that is to try to get only the strings translated that you want. Most translators are going to charge you a minimum number of words. And they are going to want the entire resource file (regardless if you translated them yourself or not). Makes sense because localizing a product means that they need to have the whole picture to ensure consistency, etc. Professional translators will probably not charge you for what they call 100% matches.
I would never ever trust the translation of my product to crowd sourcing. Ever. You get what you pay for. Besides, just because you speak a language natively doesn't mean that you can write well, etc.
How do you check the crowd sourcing translation results for accuracy and quality? In a famous and documented occurrence recently the phrase "No lorries by this route please use the main road" was translated into "We are out of the office until Monday please contact us again then" and turned into road signs that were erected.
Crowd sourcing translation has been used and FaceBook is probably the largest company i know of that tried/used it. I have not tracked their progress but you could investigate it to see it's success or otherwise. Their method of quality checking was to get other people using the translations to vote for the one they preferred, so this was a case of crowd sourcing quality control. At this point the proposal that a camel is a horse designed by a committee jumps unbidden into my mind.
Translation, in spite of all the machine pumped into it, is still more of an art than a science. To translate correctly you need to have a native speaker translating from another language into their own. So for English to German you need a native German speaker who can speak English very well to do it. Within the profession very, very few translators will translate to a language in which they are non native. The reasons for this are many but boil down to the colloquial nature of language.
To be positive you could look at how Facebook fared and follow that route. Another route would be to approach not translators, but a translation agency, there are quite a number of these. Present them with the whole corpus you want translating in the original English and get them to quote you for the whole job. This would mean someone else manhging the job and the quality and they may have shortcuts, especially if the translations are to fairly standard "computerese" type phrases. i.e.'Home', 'Back', 'Next', 'Click here' etc.
I'm creating an English translation for a program written in German (i.e. all strings within tr("...") are German). Users who are in a non-English non-German locale will probably want to see the English translation, but with the program as it is now they will see German.
There are some ways to solve this problem:
Check if it's a German locale and force to English otherwise.
Present an option to the user.
Make the programmers change their source code to English.
What is considered best-practice for internationalizing where the source code is not in English?
These are two separate questions.
The best practice is to not use any kind of hard-coded string in the sources.
Strings should be stored in external files and loaded by ID.
But what you have there does not sound like the best practice. Might be too much work to get it there.
What you describe (the tr("...") stuff) sounds like gettext (or something similar).
That approach for gettext (and similar libraries) is that "the stuff in the sources is the ultimate fallback", used if the strings for the desired language are not present.
In this case I would go with "Present an option to the user."
You can't assume the user knows English.
Real example: in Switzerland the official languages are Italian, German, French and Romansh. If I ask for French and it is not present, then the next best option is probably German, not English. I Canada the official languages are French and English, so if I as for French and is not available, the next best option is probably English.
I think the best option is asking the user (during installation probably).
Change the source to English is too costly and not worth it. I live in Brazil, we have tons of codes in Portuguese and translating to English wan't necessary one time (we do make software to english speakers). Unless you have a client that requires you to do so (usually when you are selling the source also).
Hope it helps
OK, so I guess the three options are:
Recompile the program with translated strings.
This is fraught with danger as you'll end up with two copies of the source. Bug-fixes in one will need to be done in the other. And then, what happens if you need French? Italian? Spanish? The only advantage of this approach is that it's feasible for a non-developer to do the work. (Just about.)
Resource out the strings, and automatically check what the UI locale is on load.
Here the strings are replaced with GetResource("key") or similar. On load the program automatically translates to the user's culture. This might work, but I know plenty of German-speakers who have English-language culture installed on their PCs but who would prefer German language programs at some points.
Resource out the strings and give the user the choice on load
In general it's always best to give the user control. This might be a prompt on load, although if the application is used often this can be an annoyance. Perhaps a balance is to ask the user during installation for their preference and then give then an option in a dialog to later change this setting.
Note, by the way, that translation is not localisation. For instance: number formats are quite different in Germany (e.g. 1.233,44) from English (e.g. 1,233.44). Icons and suchlike often have national characteristics.
I want to experiment with an idea I have of automatically localizing software, or at least suggesting a reasonable translation if a localized string is not available.
I'm not sure this will be working satisfactorily tomorrow morning but I just wanted to play with this idea.
Does anybody know of a dictionary that is free to use, and is in an easy to parse format, that can help me automatically translate words from English to other European languages (French, German, Spanish, etc)
The FreeDict project has quite a few relatively complete dictionaries. Most are from one language to english or vice versa, but some are between two non-english languages as well.
I don't know any dictionary but would like to point something out. You have to bear in mind that translating is not a direct word to word technique in any sense. The Rules of the language change as well and thus leave sentences unreadable. This is why even companies like Google have trouble making good translation software. Context is very hard to programmatically detect and context means everything in choosing the right word, the right structure and so on.
Maybe use a Translation API, if there is one. Google only seem to do a JavaScript API for Language.
You can't even expect to get a reasonable translation with an automatic method. Translating full texts is too hard for a computer to handle completely correct, translating short phrases correctly is impossible.
Take for example the simple text "Open", without a context it's not even possible to tell if it's a verb or an adjective. I know that at least in german that the verb and the adjective translates into two different words.
Also, computer specific concepts often borrow words from similar concepts outside the computer sphere. Those concepts often have a specific translation, but an automatic translation would sometimes try to translate it as if it was the original meaning, which can give you very strange translations.
After a while of searching i solved the problem by myself start to create my own dictionary. I do a lot of translations in my free time. In the beginning it is really boring work...but after a while you get an really good dicitionary. Some friends of mine using it too...so we all benefit from every new Word we translate.
I am designing a localized web app. I am leaning on auto-detect browser language setting. But I notice a number of respectable sites asking the user to select a language. Is there any usability issue you know of (from actual experiences out there) with just auto-detecting user language?
Thanks.
Give me a choice
Remember my choice
Use the auto-detect as default
Make transition easy
In many situation I prefer or even need the "original" over my local one, bad translations or different content being the major reason.
If you register multiple domains, you can base your auto-detect on that: When foo.com redirects me to foo.de, or otherwise shows me a german interface, it is actively ignoring my choice to go to foo.com.
MSDN did insist on showing me atrocious automatic translations and ALWAYS made me click to go to the readable, understandable english one (that's a step up: when they introduced it, the default selection for changing the language was something like Afrikaans).
Make transition easy: i.e. make it easy to go to the counterpart of the current page in a different language. Amazon often succeeds when I change ".com" to ".de", but then it fails to lead me to the german translation of the item. That's not always possible, as that requires each local view having the same structure and a 1:1 page mapping. But generally, you have to weight above requirements against other constraints of the project.
[edit] MSDN got better now :)
I would suggest to autodetect the language and display the site in this language or the default languge (probably english) if the translation is not available. Additionally present the user with a selection of languages on top or bottom of your page. The names of the languages should be written in the target language.
Don't do it like that: English, German, Italian.
But: English, Deutsch, Italiano.
Obviously there is the usability problem that you might detect a language that the user doesn't understand. How are you going to do the detection? Don't think everybody has their browser set to the correct language. IP-Adresses are also a very bad indicator for the users language.
Practical example: YouTube tried to convince me for a week or so to use the Japanese version, though I can't read Japanese. Not very helpful. Microsoft is also determined to serve me automatically translated versions of there documentation when I just want to read the English one.
So don't try to tell your users which language they're supposed to prefer, let them decide for themselves.
I really hate non-configurable auto-detection because a lot of applications are translated more than imperfectly. I would rather read perfect English than bad Russian. For example, some terms do not translate in a reasonable way, and trying to translate everything makes localized version faintly ridiculous.
Also some applications can not translate new features fast enough, leading to a mixed language.
So I always prefer to have a choice, and choose the version that is native to the application author -- for the best language (unless it is a language I do not know).
Update:
One situation when it has gone beyond ridiculous is DB2 (or its client tools, not sure), which forced me to install a Russian version, but all errors in this version were shown as "???????? ??? ??? ??".
Yes: at work, we have a Windows XP deployed with 'English' language (because we have worldwide site and only one kind Windows to deploy with only one kind of settings when it comes to language).
Yet all out applications must run in French. The auto-detect feature alone would not be enough for an appropriate display of the labels.
Sometimes when you are trying to describe something to a user over the phone and you are in a different location, it is very annoying when you are both looking at the same URL, but see different results. You might even go so far as to include the language in the URL similar to how wikipedia does it (e.g. en.wikipedia.org).
Also sometimes a user will be on a friend's computer and try to access a website but won't see it in their preferred language, because of the language settings on the computer.
I think the best solution would be to allow the user to override the setting, but default it to the auto-detected language.
I agree that the auto-detect is not enough.
Not many users know the settings for selecting their language. Therefore the settings will often be the default and therefore incorrect (for non-english users).