|
Navin wrote:
Resource DLLs are evil. There are better ways of doing things.
This is all good but in real world you are much more affected by a) the order of words in the sentence and b) dialog layout problems. Also c) it is extremely difficult to explain to translators (who do not usually have anything to do with computers except knowing how to use MS Word) what this or that out-of-context sentence mean.
So, in my unfortunate experience, the extracting of strings to a resource (text file, XML file, INI file etc.) just the very beginning of extremely lengthy, frustrating and painful process.  In many cases, it does not worth the time and efforts spent unless somebody is paying big money. Usually, "they" don't. 
MK
|
|
|
|
|
Mike Klimentiev wrote:
So, in my unfortunate experience, the extracting of strings to a resource (text file, XML file, INI file etc.) just the very beginning of extremely lengthy, frustrating and painful process. In many cases, it does not worth the time and efforts spent unless somebody is paying big money. Usually, "they" don't.
I have found the exact opposite to be true. If you give translators .RC files, they'll mess something up. It is much harder to mess up a text file. You have a good point about the context, so usually we have another group of translators actoually run through and test the complete package to make sure everything makes sense and nothing is missing. We do this regardless of how we do the original translations.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Paul Watson wrote:
internationlisation (bugger that is hard to type)
apparently hard to spell too
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
I suppose that's why I've often seen it abbreviated as i18n (18 letters in the middle.)
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Paul Watson wrote:
Us English speakers are becoming a minority on the net.
In my opinion in the future International English speakers will be the majority on the net and keeping the site in Internation English interface is ok for me rather than changing it into French or German?!
-
When in doubt, push a pawn!
-
|
|
|
|
|
Well French and German are still minorities, it is Chinese and Asian languages which are becoming the majority.
I agree about the international english bit, but localised websites will do very well. Selling to people in their native language is a strong draw card.
regards,
Paul Watson
Bluegrass
South Africa
Miszou wrote:
I have read the entire internet. on how boring his day was.
Crikey! ain't life grand?
|
|
|
|
|
Paul Watson wrote:
localised websites will do very well. Selling to people in their native language is a strong draw card.
Yes,I totally agree with this since almost everyone loves his/her country and it will also help to local people to find job easier(without knowing advanced English) but this won't be easy because of Globalization.
Paul Watson wrote:
Chinese and Asian languages which are becoming the majority.
Yeah I can understand the problem right now
-
When in doubt, push a pawn!
-
|
|
|
|
|
One of the questions I ask myself a lot is, "What requirement does this line of code map to?" If I find the answer is NULL, then I'm just coding for the sake of coding and not doing my clients much of a favour. What's this got to do with Internationalisation? Well, I make sure early on that the client signs off on Internationalization. A project's architecture, source control checks, and build scripts can be significantly impacted when you start adding a set of resource DLL's needed to support internationalization.
Chris Meech
If you spin a Chinese person around, do they become dis-oriented?
Why do people in this time period worry so much about time traveler's destroying their worldline when they have no problem doing it themselves every day? John Titor.
|
|
|
|
|
We are a global company, and even software that we write in English-only could at any time need to be translated into any arbitrary language.
So from the start, I always make sure that my apps will work seamlessly in another language. Usually for me that means pulling out any strings displayed to the user and putting them in an INI file (can be Unicode or ASCII, depending on the needs), and making sure our stuff will work when compiled in Unicode or MBCS. Now, 99.99% of the time, the only thing we do with strings is display them to the user in some form (be it in the UI or in an output file), we don't do a lot of sorting, string manipulation, etc., which makes being aware of what character set you're using more important.
And, of course, we have a set of classes to make i18n simple to add to any app we make.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Waaaaa, you are really amazing.
Usually for me that means pulling out any strings displayed to the user However, IMHO, "internationalization" can not live without "localization".
Your income: "52.000" Birthday: "01/11/03"
If your application receive above input, what are "Your income" and "Birthday"?
To me, "localization" is another issue (different from internationalization) but, most of time, the person-who-assign-pay-check is not happy if "internationalization" != "localization"![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
You are right... though there are handy APIs any time we need to display something like that which is locale-dependent. And they are not much more effort to use than just a normal print.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Okay...I'll admit that I'm not the most experienced programmer in the world, but 'Internationalizing' an application really depends on a number of factors. If the product is destined to be used ONLY within the USA, then why would you bother (and before someone says "well, we have people that speak other languages in the USA", let me throw in that I feel that the de facto language for the USA 'should' be American English. Nothing against others, but it is the language that our country was founded on.
Now, for applications that are written with International deployment as part of the project scope. For those applications, there must be a project requirement for 'Internationalization', else the project isn't really worth deploying.
Sorry to be so nit-picky, and I'm sure that my view(s) may be a bit utopian in nature, but I do feel that we (programmers) should keep the bar set as high as we can! 
Regards,
KoalaCowboy
Knowledge Monger
|
|
|
|
|
I agree with you. If you need another language later on you just do the stuff later. It's not like there is any major restructuring of the program just to add multi-language support. The total effort is just the same. And if it turns out that you never need it to be localised then you have not wasted any effort.
|
|
|
|
|
I couldn't disagree more. When you are first writing an app, it is easy, almost trivial, to ensure your app will work with other languages. But if your app has been around for 2 years, and then suddenly you have (read: could make a lot of money) to sell in another language, it will be tedious, time-consuming, and error prone to try and rip out all the strings and put them in files or resource DLLs, use _T for all your strings, etc.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
In all fairness, wheither you put the strings into the resource files earlier or later, the total effort is the same.
|
|
|
|
|
I disagree. It is much less effort to put them in from the beginning. Otherwise, you have to hunt through your code for strings, and that is a royal pain. And you usually miss some.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
Thanks for that viewpoint! I guess from a "in process" standpoint, where the application is not yet fully created, it would definitely make more sense to just ADD the feature of multi-language support, even if not used; As you said, it would be much easier to have it IN the application by default.
KoalaCowboy
Knowledge Monger
|
|
|
|
|
Many applications get written in the "main market language", until marketing decides that Kuala Lumpur would be a good target too, and after a few failed attempts gets a clue that maybe a menu readable for a Kualalumpurian would increase the chances of the product being bought.
Ignoring the mere idea that an application could be needed in a different language environment is a little bit stupid.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
Ja, ich stimme Dir zu. Auch mich kümmern die Ammis nicht. Es stimmt zwar, der gewöhnliche Amerikaner ist unfähig, eine richtige Sprache zu lernen aber was solls ? Muß er halt mit Deinen Programmen leben.
Viele Grüße
aus der guten Alten Welt.
|
|
|
|
|
meinen Esel weg lachen!
O.K., O.K.... erhalte ich die Anzeige! Verbessern Sie, um JETZT zu erlernen, während ich noch ein ' Newbie ' in der programmierenwelt bin!
KoalaCowboy
Knowledge Monger
|
|
|
|
|
Babelfish(?) can do incredible things to a apparently simple text.
|
|
|
|
|
Most of the scientific vocabulary used in my programs is english anyway. Almost all of the papers describing the background of our programs and the results generated with our programs are english. You cannot attend a scientific meeting without knowing english at least a little.
So, where is the point in translating our software into several outer mongolian dialects that write from the bottom of the screen up and use different colours for punctuation?
Whoever even considers to buy our systems is able to read and understand english texts anyway, so we (including our marketing) does not feel the urgent need to find out what 'laser attenuation' is translated into Fulbe. 
|
|
|
|
|
KoalaCowboy wrote:
the product is destined to be used ONLY within the USA, then why would you bother
You wouldn't. 
But very few companies would want to restrict potential international deployment due to technical reasons. Of course, one would need to weigh the cost/benefit of supporting internationalization from the get go, since this is really a feature that's built into the app, not tacked on later.
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
The software I write (see sig  ) is always DBCS-safe and language-neutral -- it's just a habit now and it's not hard to do once you know the DBCS rules.
At work, however, our product is US-only and I'm the only developer with any internationalization knowledge, so I fear the day when we have to make the code work in some other language. And if it's a DBCS language... 
--Mike--
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
CP SearchBar v2.0.2 released
|
|
|
|
|
Michael Dunn wrote:
it's just a habit now and it's not hard to do once you know the DBCS rules
Agreed. #define UNICODE, #include "tchar.h" and the occasional WideCharToMultiByte() or MultiByteToWideChar() and you're all set. Localization is fairly easy, as long as you diligently use the NLS information Windows provides.
Michael Dunn wrote:
I fear the day when we have to make the code work in some other language
Agreed2. I do the UI's on the products my group is responsible for. You would not believe the grief I got when I insisted that file paths had to be passed by the UI to the underlying code as wide character strings. The fun part is: our third beta site is in Japan. Even though the application has not been translated, the folks over there still expect it to accept Japanese file names and such.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
