|
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;
|
|
|
|
|
That depends on who the application is being written for. If it is a project for a local government organisation, etc. then there is no point, if it is for a multi-national (or a client whose locale is different to mine) then yes, I try to code for localisation.
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
|
|
|
|
|
We localise our app into 9 languages, including Japanese, Chinese and Russian.
We weren't able to get it to work under Arabic, because we have to support all platforms (including Win98). I'm not charge of the localisation, so I don't know the technical details, but I understand it's extreemly difficult to localise an app to Arabic under Windows.
I'm curious has anyone successfully ported a C++ app to Arabic?
|
|
|
|
|
The Windows 9x environments are notoriously difficult for handling bidirectional text. From what I understand, it's much easier under Windows 2000 and XP. You might consider localizing your app for the Middle East under those versions, and drop support for Windows 9x (at least as far as Arabic support goes).
Software Zen: delete this;
|
|
|
|
|
Yeah, Hebrew and Arabic are difficult becuase of the right-to-left reading order. If you're careful it can be done though, you may manually have to flip some controls here and there to make it work out right. I personally have not had to do it (yet...) but some other groups in this company have, and while it's tricky, it's not impossible.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
I was developing something (actually it was more of a test and practice) that had to be localised using C# and Visual Studio .NET and there was no problem whatsoever to get it into Arabic. All I needed to do was to set Localizable property to True (Inside Visual Studio .NET) and choose the language for which to localize it. For Arabic you need RightToLeft set to true, and the VS.NET will generate the appropriate sattelite assemblies. Also with Visual Studio.NET you get a very nice tool (very nicely hidden) which is called WinRes.exe so you can send your resx files and winres.exe to the translation people and then integrate that with your project.
This project was done on Win2K and WinXP, but I think it should work on Win98 as well. Also, if you are interested I have little Culture Explorer utility that I wrote which demonstrates the capabilities of .NET Framework's internationalization. So feel free to email me on huseinr@epn.ba
Best regards,
Husein
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
