Slashdot Mirror
Microsoft Forced To Translate Office Into Nynorsk
An anonymous reader writes "Beeb reports, "The main organisation working for the Nynorsk language got most of Norway's high schools to threaten to boycott all Microsoft software if they didn't come up with a New Norwegian version of Office." Which brings up questions for Open Source developers: What's involved in translating programs? Is there a process that can be followed to make the inevitable easier? Is there a group providing guidelines for this already? -- Do you work in program translation? Step up and do tell."
So I'm boycotting Microsoft, too, until they release Office for *nix.
In a sense, though, this is kind of what is supposed to happen with big customers.
But it is sad that the emphasis seemed to be getting MS software. They should have bought from whomever decided to provide the software in their language.
Oh well.
GNU gettext already solves the problem of multi-lingual program messages. So the answer is, its easy to write multilingual programs
Think about it... they want software in their language, and it's not available. So...
- If it's closed source (MS Office), don't buy something you don't want, and tell the company what you do want. It's called "market pressure."
- If the sofware is open source, you can translate it yourself -- and likely have working, native language software faster than a closed-source solution.
This is news because they managed to get Microsoft to support a language (spoken | written | read) by (relatively) few people. The only reason Microsoft probably even paid any attention to them was the threat they'd teach the children anything but Microsoft products.Would this have happened in the absence of open source? I doubt it. I guess that means open source is working. (Strange way for it to 'work' though...)
"...America's great minds of today, teaching America's great minds of tomorrow. Poor bastards." -- A Beautiful Min
What's involved in translating programs?
:(
It's not just as simple as translation from English to some-other-language. It involves new character set, input method and association helpers, language-specific formatting etc. In the case of Chinese version, they even have to deal with different encoding methods support in one product.
As a developer I always find merely I18N support in Linux not enough to deal with all the language-specific problems. We've very little choice here. I can understand that without commercial drive it's very difficult to develop a language-specific product. E.g. majority of the fontset we need are not free.
Yes, but they place the resources (strings, icons, bitmaps, etc.) in a "satellite DLL" that is loaded depending on the system's codepage and locale identifier. If you look at an installation of, say, Office or MSDN you'll see subdirectories with the LCIDs (1033, 1054, etc.) and DLLs inside them. Each of them corresponds to a different locale.
Of course it gets complicated with the LANGID, SUBLANGID, whether or not the IME is enabled (W2K and XP) and so on. But that's the technique.
I'm sure the Norwegians can handle the English version of Office just fine.
Having worked with many Scandanavians, I am truly impressed by their command of English -- many people from Norway, Sweden, Denmark, speak it better than many US people do, and definitely better than people from any other (non-native English speaking) country.
I think the fluency in English for Scandanavians arises from the similarity of English to the Scandavian languages, so picking it up is natural, much more so than other European languages, and of course, better than any non-Western language.
But in any case, not having Norwegian Office is not as a big of a cripple to productivity as the article may lead you to think.
There's 10 types of people in this world, those who understand binary and those who don't.
Yeah. Except that the "professional translating company" has no clue at all about the context in which the strings will be used... and that guarantees some really funny results. At least that's my experience.
Using Cocoa under Mac OS X, and Project Builder (free download from http://connect.apple.com ), the process is very easy. You can build different GUI files for different languages if you like, and use different plists for the different strings. Different widgets exists so that fields are displayed according to internationalised preferences too.
Often a speaker of another language will do the translation, and send the files to the developer for inclusion (this happens all the time). It really is that simple. And of course the entire application appears as just a single icon in the finder, so the end user doesn't have to worry about keeping their resource files with the application when moving the application around.
When you translate an application it is not just translating text strings in it. You also obviously need to update documentation, online help, etc. This, as a lot of people have pointed out, is "simply" a matter of changing text strings that are external the the main source code, and referenced by the application throughout the code.
However, as well as translating text to another language, there is a lot more work to be done. Images in the interface may need to be changed, sounds used in the application, etc, may also need to be modified for the appropriate localisation. The entire user interface must be examined for culturally specific items and they need to be modified for the appropriate target market.
To allow for localisation, an application should be internationalised as it is written. How this is best accomplished is determined by the Operating System you're writing for. Most operating systems will have internationalisation features to some extent.
For example, applications written using Cocoa for Mac OS X are easily designed for localisation at a later date. Looking inside any Mac OS X Cocoa (and some Carbon applications that use packages) you will see folders named "English.lproj", "French.lproj", etc (inside Contents/Resources). These folders are how Mac OS X can automatically localise things. Any application written using the guidelines posted by Apple is ready to be localised without any changes to the code. All that needs to happen is the modifications to the interface resource files, this can include changing the complete layout of dialog boxes, as well as simple translation of text strings.
Overall, any application should be coded as if it will be internationalised. Even if you do not intend to do internationalisation, it enforces separation between the code and the interface and resources, which is almost always a good idea.
The hardest part is really translating correctly the text, taking into account the particularities of every language, the customs,... and obviously, keeping the translated version up to date.
It's not always as simple as substituting words. For example, a page layout or dialog box that looks great in English may look terrible in German because the average word length is greater. Don't even get me started on languages that don't go in the same direction!
My experience of building applications that work in n languages (I've done >14 languages before, including non Western European character sets) is that you have to start thinking about it from day 0. It's very difficult to retrofit internationalization onto an existing application.
A separate file is a good beginning.
Here are a few other things that really help:
Foreign words tend to be longer than their English equivalents. Double available space for captions.
A routine that walks a form and grabs all component names and captions. It then throws these up in a grid and lets the user translate them.
A TranslateForm procedure that uses info from above.
Don't forget reports. If you have something that can also crawl reports on the fly, that is a huge timesaver.
It also helps to wrap some common ShowMessage and InputBox functions in something like ShowMessageTranslate, etc.
I do a lot of RAD projects, and the last thing you want to do is burn up mental cpu's with translation issues when you are in the heat of getting something to work. Spend some time on these issues beforehand by writing or using good utilities.
If anybody wants it, I have written a complete package for Delphi. There are better and worse on the web, I know mine works. ghelmke@online.no
If you got a $100 bill, put your hands up...
I was a tester on Ericsson's first smart phone project.
Although they approached the problem of enabling easy translation of displayed strings by using resource files, etc (this was enabled by the Symbion OS, which strongly encourages such practice), we ran into two major problems:
1. Buffer over/underruns -- if a programmer had created a string (e.g., menu), they would allocate four characters to store that string, but often the German equivalent would be, say, 50 characters, which would cause a crash.
2. The smart phone had a relatively small screen (compared to a PC). The UI designers were working in English and designed the entire UI using English words. They didn't pay enough attention to the fact that translation would be required. For languages that tend to have longer words than English (e.g. German), this caused significant problems. These translations wouldn't fit in the allocated space, and the screen would be cluttered with text.
It would be nice to see software engineers working on UI toolkits to take problems like this into account. Ideally, applications (and GUI toolkits) should be designed in a language-neutral way. Application programmers, who typically think in terms of logic and who strive for elegance, aren't really the best sort of people to be considering language translation. It would be desirable for GUI toolkits to degrade gracefully when presented with text that doesn't fit the UI design and which does not let programmers make the buffer over/underrun mistake. It would seem likely that such a framework exists, but it doesn't seem to be ubiquitous.
"The noble art of losing face will one day save the human race"---Hans Blix
What's involved in translating programs? Is there a process that can be followed to make the inevitable easier?
We recently hired a translating company to translate the strings of a project into several languages - and found out gettext's po files were too "complicated" for them (apparently some people are scared of anything ASCII).
Since the project is using Qt anyway, I converted it to using Qt's translation mechanisms, and gave them a CD that boots a basic Linux system with Qt Linguist -- they could handle that.
I suppose if we want more translators to help us out, we need a similar tool for po files - any volunteers for hacking up Qt Linguist to support both formats?
Except for software that actually processes words where the algorithms are geared for English, e.g., word processors (word selection for non-Roman languages or those that go right-to-left), search engines (the Porter word-stemming algorithm).
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Consider my ongoing project to translate Nethack into something resembling Spanish. Gettext offers support for plurals, but not for gender; it provides no way to make sure that a blessed sword (espada) is bendita, but a blessed helmet (yelmo) is bendito. Languages with noun cases, such as German, Finnish, and Russian, have an additional problem: a monster is a subject when it hits you and a direct object when you hit it. Furthermore, sometimes Nethack must parse user input, as when making a wish, and differing word order and words with more than one meaning create lots of pitfalls there. Finally, Nethack is laden with jokes and puns, and many of these don't survive translation.
Ooh, moderator points! Five more idjits go to Minus One Hell!
Delendae sunt RIAA, MPAA et Windoze
... is not as simple as I thought it would be.
Currently I am involved (for the first time) in localizing a very complex product (sells for about 150,000).
While we have a nice (actually free) product to look at the GUI elements while translating them, the messages of the product come with no context.
In all modesty I can claim to know this product better than anybody else in my country (the product was developed overseas but I was in touch with the developers almost from inception). Nevertheless without context I sometimes have no clue what some messages are supposed to mean.
I would be surprised if this problem had already been tackled in the OpenSource World, if so please prove me wrong. (Disclaimer: I haven't been involved in localizing OpenSource products. My own stuff I write with an English GUI anyway).
From my experience I'd say that there is more to a localization framework than a central place to store all messages and GUI texts.
The latter is indispensable to be able to localize the software at all, but it does not make for a comfortable straightforward translation process.
For each message there should be context information that tells the translator under what circumstances the message string will appear for the user. Without this information a certain percentage of your translation will always end up being guesswork (depending on the complexity of the product).
Happy 2003 to all.
Most people would also be surprised to know that the largest english speaking country is China.
Not in any meaningful sense. Chinese speak Chinese to each other. Even if over 25% of the Chinese population speaks some English, that doesn't mean they speak fluent English, or that they could read or write something of moderate complexity without a dictionary.
America makes up a very small part of the total english speaking world.
Well, America makes up almost 300 million people. Even assuming everyone in the world speaks English, that's still 5%; and while a lot of the world speaks English, a country aren't really part of the "english speaking world" until they primarily speak and write English. So Australia, New Zealand, U.K., Ireland, U.S., Canada, and to some extent India and Africa. Of the solidly English speaking countries, the U.S. is the largest.