|
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
|
|
|
|
|
Hey, I've been looking into this for my project, Fluid UI Toolkit[^]. I'd greatly appreciate some advice on this. I'll send you my email address if you're able to help me here.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
Yeah, sure I will help you. If you have any question please feel free to email me, or I could write something up based on my experience. Probably my very first CodeProject article. 
Husein
|
|
|
|
|
|
Do you think localization is always a waste of time? I'll admit, it seems like we spend a lot of effort on it with my company's products. I'm not sure we ever receive an adequate return  . We do quite a bit of business in Europe and the Pacific Rim, but the bulk of the money is in terms of hardware which is locale-agnostic.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
