| Date: | September 29, 2003 / year-entry #75 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20030929-02/?p=42363 |
| Comments: | 20 |
| Summary: | Answering a comment from an earlier entry. |
In
a previous entry, I said that the word "Start" disappears because the alternative
is worse.
Somebody in a comment asked, "Why not draw the text vertically?" Ah, now you get to learn about the exciting world of vertical text. We originally intended to run text vertically in the new XP Start menu. In original designs for the menu, your name ran vertically up the left side of the menu instead of running across the top. Rotating text is problematic in languages that traditionally run vertically, such as Chinese. Since you probably don't have Chinese fonts installed, pretend that %, &, and ' are the Chinese characters for your name. In traditional vertical text, it would be written as shown in Example 1 below. Notice that the English text is rotated clockwise. This preserves the top-to-bottom reading order.
As a concession to Western influences, it is permissible to render Chinese characters left-to-right, in which case your name would be written as "%&' (Amy Smith)". Compare this to the traditional Western way of rotating text. Text which would normally be rendered as "Amy Smith" is rotated counter-clockwise and rendered as shown in Example 2. Now consider what happens if you take a Chinese name rendered the Western way, "%&' (Amy Smith)", then rotate the Western way, resulting in Example 3. Notice that from a Chinese point of view, everything is upside-down! The character that is supposed to be at the top (%) is now at the bottom. Windows for many years now has been multilingual. This means that the same underlying code runs regardless of language. Changing a language merely changes the strings being displayed. This means that there can be no language-specific UI. In this case, it means that we can't have separate rotation rules for Chinese as opposed to English or German. (And even if we were allowed to have separate rotation rules, we would have to be able to tell whether the name was in the form above or was in the form "Amy Smith (%&')". In this form, we should rotate it as in example 2, since this is an English string with Chinese characters embedded; as opposed to our example above where we had a Chinese string with English characters embedded. Those of you who have seen Arabic and English mixed together get to see punctuation marks bandied about with similar degrees of confusion.) Multilingual support also explains why you see things like "1 folder(s)" instead of "1 folder" and "2 folders". Why not have two format strings, one for when the number of items is exactly one, and one for when the number of items is two or more? Well, for one, that would significantly increase the number of strings we would have to carry around. (If you say "just add s to make the plural" then you really need to get out more!) For two, some languages (such as Slovene) have a "dual" number in addition to singular and plural. The Lahir language has singular (one), dual (two), trial (three), paucal (a few), and plural (many). So now you have to have perhaps five versions of every string that contains a replaceable number. This also explains why you see a lot of strings of the form "Property: Value" (for example, "Last modified: Monday, September 29, 2003") instead of a phrase ("Last modified on Monday, September 29, 2003"). This is necessary to avoid problems caused by grammar. If you attempt to compose a phrase, you have to worry about subject/verb agreement, gender and number agreement, declensions, all sorts of things that computers aren't good at. The only safe solution is to avoid it entirely and use the "Property: Value" notation instead. We did get one special exception to the "grammar independence" rule: Personalized folders. When you view somebody else's "My Documents" folder, it says "Chris's Documents". We made this request to the translators and they worked really hard to make sure that the templates for possessive forms were accurate in all the languages we support. (Fortunately, we didn't have to deal with languages where the form of the template depended on us knowing whether Chris is a man or a woman.) |
Comments (20)
Comments are closed. |
Im not so sure about rotating english text clockwise. I find english text is most readable when it is rotated either counter-clockwise or so that the bottom of the text points towards the centre of the working area. So if the title is on the right side, it should be clockwise, if it is on the left side, it should be counter-clockwise.
>Fortunately, we didn’t have to deal with languages where the form of the template depended on us knowing whether Chris is a man or a woman.
Just out of interest, can you give an example of a language in which the templates need to conside the subject’s gender?
On a more general note, is there a set of documents, sites or guides that provide a good reference internationalising programs from a developer’s perspective or is this highly dependent on liasing with the localisation team?
BTW, another great article. We need to see all these collated into a book:-)
There are a ton, but here’s the microsoft one :)
http://www.microsoft.com/globaldev/getWR/steps/wrguide.mspx
In Italian, one would say "Documenti del Chris" or "Documenti della Chris" depending on whether Chris is a man or a woman. The translators used "Documenti – Chris" as a workaround.
Did you know the toolbars in Office XP rotate the text 90 degrees if you drag the menubar on to the side of the application.
As to multiple formats of strings according to the number in front of it.
Solving it with adding "(s)" is not very good and works only for English too (i.e. in Czech you would have to write "2 soubor(y/u)", becouse we have different endings for 0,1,2-4, 5 and more.
Anyway, Java has framework which tries to address this (format string for files in English is: "There {0,choice,0#are no files|1#is one file|1<are {0,number,integer} files}." displaying "there are no files", "there is one file" and "there are X files". The same would work for Czech and many other languages I guess…
Why not to implement it this way? :-)
And to SC — as for subject’s gender — in Czech you have to decline the other way, so you would have to decline the name right to obtain right "one’s document" (Jakub -> ‘Jakubovy dokumenty’; Bara -> ‘Bariny dokumenty’ etc.etc… :-))
This one really depends on the very rules of the language as how to express posessions. Not easy :-(
>Rotating text is problematic in languages that
>traditionally run vertically, such as Chinese.
But when I saw screenshots of Chinese Windows, the text in dialogs was placed like in ‘normal’ languages?..
I don’t get it:
>Now consider what happens if you take a Chinese name rendered the Western way, "%&’ (Amy Smith)", then rotate the Western way, resulting in Example 3.
Example 3 is a counter-clockwise rotation, so it is not Western, Is it?
I suppose that rotating any text clockwise is safe for both English and Chinese, providing that the "regular" Chineese text is rendered in a Western way i.e horizontally.
I say stick with the native (ie US English) language for the interface, and allow all the multilanguageness for user input :) And no, my native language is Russian and in Russian we have many such joys like: 3 templates of declination which have *some* (but not one-to-one) connection to gender; different forms for singular odin fajl (1 file), dva|tri|chetyre fajla (2|3|4 files), pyat’|desyat’|neskol’ko|mnogo fajlov (5|10|several|many files), etc.
The Nautilus file manager from the GNOME desktop contains this function to generate something similar to "Chris’s Documents":
static gpointer
default_home_link_name (void)
{
/* Note to translators: If it’s hard to compose a good home
* icon name from the user name, you can use a string without
* an "%s" here, in which case the home icon name will not
* include the user’s name, which should be fine. To avoid a
* warning, put "%.0s" somewhere in the string, which will
* match the user name string passed by the C code, but not
* put the user name in the final string.
*/
return g_strdup_printf (_("%s’s Home"), g_get_user_name ());
}
When I posted my question to the original article about the Start text, I hadn’t actually considered rotating the text, but was just arranging the letters vertically.
S
t
a
r
t
This would seem to solve the vertical language issue because all the characters would be treated in the same way. This may not be acceptable for a long string of characters, but it might work in the specific example of the start button where the text is static and (presumably for most languages) relativly short.
P.S. I have not had to deal with non-western languages before in programming. I can see it opens up a world of new issues that I have never considered.
Looking at my bookshelf, I question the existence of a "traditional Western way of rotating text". American book spines read top-to-bottom (the opposite of Example 2), but most European books I’ve seen go the other way. I think this is true for CDs as well (I have a lot of "upside-down" import CDs on my shelf).
Great explanation of the "folder(s)" rationale…sadly I still see apps saying things like "1 minutes" out of what I assume to be sheer laziness. :-)
Here’s a great article on the problems of localization
http://www.perldoc.com/perl5.8.0/lib/Locale/Maketext/TPJ13.html
Here’s a great article on the problems of localization
http://www.perldoc.com/perl5.8.0/lib/Locale/Maketext/TPJ13.html
To SC — In Portuguese, if Cris (Portuguese for Chris) is a man, you’d say:
"Documentos do Cris"
If Cris is a woman:
"Documentos da Cris"
While this posting is quite interesting and illuminating, and I hope that a great many developers will read it and thus lose some of their linguistic ignorance, it is still only the tip of the iceberg.
In English it is reasonable enough to read things like "1 file(s)". In languages where you have three forms, like some people have already mentioned, "1 fajl(a/ov)" looks really odd — and that’s just a special case because one of the forms is a prefix of all the others! What about "1 user(s)", which would probably look something like "1 polzovatel(‘/i/ej)" (where the apostrophe represents an actual Russian letter)? What about words that have an entirely different plural: should you write "1 rebyonok/rebyonki/detej" or "1 rebyon(ok/ki)/detej"? What about your own example of Lahir, which has not three and not four, but five different forms?
The only way to keep a user interface professional-looking is to actually perform an algorithm to cater for the rules of each language. This is not actually too difficult; I and many other developers have done this.
As for rotating text — what you said does not convince me. If you rotate text that contains Chinese characters counter-clockwise, a Chinese person will certainly *not* think they are upside-down. Certainly you can distinguish a normal "e" from a 90°-rotated one; similarly, a Chinese would notice that the characters are 90° rotated — as in, each character’s actual appearance, not just their relative positions — and thus read it with their head tilted and realise it’s the Western-influenced order.
As for the gender-neutral possessives, well, several people in this thread have already pointed out that your claims that this worked in every language are entirely bogus. The Italian, Portuguese and Russian translators apparently had to come up with workarounds — I have no idea how much the translators for languages even less related to English were racking their brains over it.
What you have silently skipped over is all the issues relating to number representation (decimal points and thousands separators; not to mention that Japanese uses ten-thousands), date and time formats, etc.etc.
Additionally, the translation system you describe where "%s" is used to place variables in a string is completely insufficient, inefficient, and unnecessarily difficult to use for translators who are trying to concentrate on the task of translating text into another language rather than figuring out how positional arguments work. If you have two %s’s in your source string, and the translator needs to put them in the other order, this should not be considered a special case. Additionally, "%s" gives the translator not the slightest clue what %s means and what sort of text or information is going to be replaced in its stead. This is why even languages closely related to English, such as German, have embarrassing mistakes in their translations of very short strings — the bottom of the Search Files/Folders window, while searching, reads "Searching %s…", where %s is the current directory. Had the translator known that %s was going to be replaced with a directory path, they probably would have used the correct translation "%s wird durchsucht…", but since they didn’t, they provided the nonsensical construction "Suche %s…".
Some more issues that I have come across are keyboard navigation keys (what if a language has, say, only 18 letters and there are 19 options in the dialog?), context-dependent identical source strings (you may have used the term "current account" in two places in your English software, but in German one may have to be translated as "aktuelles Konto", another as "laufendes Konto"), string grouping (translators should know what strings occur together in a dialog, and what strings are in entirely different dialogs), and "hidden" strings (developers often forget that things like URLs or e-mail addresses may also need to be translatable so that a Swahili user can reach the Swahili version of the site and contact the Swahili support team).
Internationalisation is a far more complex issue, and most problems are not as easily overcomeable as you are claiming them to be.
I’ve enjoyed reading Raymon Chen’s series of articles about different historical aspects of Microsoft Windows. Today, he writes about why you can’t rotate text….
Commenting closes after two weeks.
http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx
A few days ago Elliotte Rusty Harold blogged about The Downside of Localization. He gave the example of the Xerces XML parser and how error messages are now available in various languages. Mr Harold correctly recognized that this could introduce a new