|
The next poll should be: What other languages do you want to see The Code Project in?
That should keep Chris busy... 
Us English speakers are becoming a minority on the net.
We can do internationlisation, but don't build it in by default. We do bespoke products though, not shrinkwrap so any future internationlisation (bugger that is hard to type) work we can charge to the client. 99% of the time though the cost puts them off.
Recently I have learnt to put strings into a resource file though. Having had to go through a thousand pages changing error/warning/information messages was not fun.
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?
|
|
|
|
|
I think Chinese would be easy... just convert everything into random skwiggly hieroglphics ... well it'll look chinese to me!
|
|
|
|
|
Paul Watson wrote:
Recently I have learnt to put strings into a resource file though. Having had to go through a thousand pages changing error/warning/information messages was not fun.
Having a few 1000 strings in a monolithic resource files isn't my idea of "joy" either.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
Tis better than having them scattered amongst those 1000 files. Means you can edit them in one place and have multiple versions for different copies of the project etc.
How do you do it?
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?
|
|
|
|
|
Moving all String const defs to the top of the file, and praying that my clever scheme I plot works out once I have to internationalize.
I agree that the one place is better - but that the one place is unstructured is a real pain.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
sighist | Agile Programming | doxygen
|
|
|
|
|
peterchen wrote:
Having a few 1000 strings in a monolithic resource files isn't my idea of "joy" either.
I agree - we use text/INI files for our strings. The INI style is nice because you can group related strings into sections. We could even split them over multiple files, but we haven't really had a use for that yet. It is nice to have the strings separated from everything else - we can just send them to translations and there you go.
Resource DLLs are evil. There are better ways of doing things.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
