So, yesterday I was playing around with GUIs in processing, and funnily enough, it was quite hard to google concepts on how to support multiple languages in a GUI. With that I mean the spoken kinds of languages, not programming languages 😉
It’s really hard, you think you found a good keyword like “multi-language UI”, and it does work in some contexts, but it’s just.. well, try it for yourself. In the end I added words like “English” and “German” as keywords, which led me to “gui translation”.. / localization of software. [Link to decent wiki article]
Obviously, I’m not to first to write this kind of code, so there are a number of packages and codes online.
For example, there is Localize, which seems like a really nice KDE package, but it’s overkill for me.
I really, really like gettext (GNU), and I would use it for bigger projects and as a starting point for researching on how to write my own adaption for my rather specific toolchain.
In the end, I decided to use a really simple csv file and lookup.
Somewhere in the beginning, the language is chosen (beware, pseudocode), and an array is created. A small function translate(“Open”) searches the array, accesses the right language and returns the value (like “Öffnen”, if you speak German). In your regular code, you only use Button.Text=translate(“Open”) and write that Open into your csv/Excel-File and you are fine. Very readable, very simple.
I didn’t specify the implementation of the translate-function for one very specific reason: Depending on the number of entries in your “database” and your computing hardware (memory/speed), you could use a simple search or hashing or something very different.
I should probably add that I did consider writing a nice pre-compiling macro, but I’d rather make the decision at runtime. And to be frankly, right now I don’t write large enough GUIs for that. Most of the time, I write algorithms..
But I’ll probably write that small “translate”-dll that does exactly this… with error handling (What if “open” doesn’t exist? .. Add it to the file and return an empty string..) and some other goodies introduced by gettext. It would be reuseable and..
jeez, I’m starting to sound like my boss.
Right, simple c-dll, 2 pseudo-code-functions:
int setLanguage(“German”) //return some error code
Ugh.. I hate returning c-Strings, especially considering that I want to use this for multiple languages.. , including LabVIEW… Maybe BSTR? Or a fixed field length (like 256bytes, you can always append words..)?
Seems to be the easiest way out and I don’t want to spend the entire evening researching safe/efficient memory allocation anyway..
And I’ll have to specify my format (First row, language name..), error-codes for my personal error-handler library (guess who inspired me to write this one..?) and use some config-File.
Regarding config-Files, I’m really thinking about very practical aspects of software architectures right now. Should those kind of files (like the error handler or the translation dll or their config files) lie in one folder? Should the folder structure mirror the project folder structure? Should I use a common interface to parse config files (as in: write them as xmls?)
Why xml? Why not?
I’ve been in a very productive, but weird kind of mood for the last weeks: Every idea sparks another one, every line of code I write gives me another idea, another thing to research, another thing to do..
So much to do, so much to learn..