If you are distributing an app for use in many countries, what are the basics that a developer should be concerned about?
for me, i have a few table with different column for the different language. i have table for report, screen, error message etc. when i open a form, the code on the open event go to the table and get the right language and loop through all the control for labels, buttons and assign right language to those controls
the most important is make sure your name all the controls on the form correctly
Most important is to enable the user to select the language, do not have the application automatically select the language based on the operating system/location or something else. Many users have no choice about the operating system/configuration they use as it may be a corporate standard and not in their preferred language. Also keep in mind that some countries have more than one national language, so again allowing the user to select their preferred language makes sense.
i agree with james… i got client using a English MacOSX but my application in french and another french client with French OSX running an english version of my application.
To add, having had a quick look at the video link posted, I’d say it is not very useful because it does exactly what I suggested you should not do!
Another thing to keep in mind is data interchange when it comes to date/time, currency and so on: if I run your app on my Swiss-German PC, save a file containing dates and send it to a fellow worker in the UK, who also runs your app, he should be able to open it and so on.
to make sure that the date/time show up ok, i have the Date field as date datatype and keep it as YYYY-MM-DD and on the form, show up the correct date format DD/MM/YYYY in UK or MM/DD/YYYY in US
have not idea that 2014-02-22 is a ISO format
Ya, I’ve found sticking to ISO formats at least gives me a fighting chance of be able to support users who want to use my data in other apps they own.
Firstly, have the texts translated by a native speaker of the target language, preferrably a person with knowledge of the terminology for the application (i.e., if you’re writing a banking application, make sure they know the terms bankers use). Do NOT use a translation program, Google translate or similar – I once saw a manual originally written in Spanish and translated into English with a translation program, with the word “bomba” translated as “bomb”, which is indeed one of its meanings, when the other meaning, “pump” was the correct one.
I develop multi-language applications. I put all the texts in an SQLite database and read in the appropriate version for each window during the window’s open event. Yes, it requires much more code than including texts in the source code, but it does allow the language to be changed according to the user’s wishes.
Thanks for all the great information.
Almost all the strings I use are for error message dialog boxes. Is there a clever way to organize text constants for message dialogs?
How about concerns for foreign languages when developing an app that utilizes the built-in database? Does it default to UTF-8? Also, I read that one should use ConvertEncoding before storing any data in a database, but is this necessary when using prepared statements?
Thank you
It would be if the statement includes accented characters such as:
SELECT * FROM dbase WHERE name='Jos'The whole encoding thing is a royal pain. Many of my applications involve accented characters. The only reliable way of handling them that I’ve found is to do the conversion on the entire statement immediately before executing it, for saving to a database and reading from it.
I just reread the documentation for SQLiteDatabase and it says, “SQLite converts all text in TEXT columns to UTF-8 encoding.” So then using ConvertEncoding on all sql is an unnecessary step, correct?
what i did is to find out the accented character and change the SQL Statement
SELECT * FROM dbase WHERE name LIKE ‘Jos_’
The sqlite based plugins (real sql & sqlite database) are NOT compiled with ICU included
Doing so would increase the plugin size by a significant amount
See http://www.sqlite.org/faq.html#q18
Having ICU included would enable using unicode for data, queries etc
BUT it still would NOT get rid of the need to define the encoding when reading data from the database since what you get back are basically “bytes” with no encoding information
I’ll take that as a “No” I don’t need to use ConvertEncoding when looking to store data as UTF-8 in and SQLite database.
[quote=68253:@Norman Palardy]The sqlite based plugins (real sql & sqlite database) are NOT compiled with ICU included
Doing so would increase the plugin size by a significant amount
See http://www.sqlite.org/faq.html#q18
Having ICU included would enable using unicode for data, queries etc
BUT it still would NOT get rid of the need to define the encoding when reading data from the database since what you get back are basically “bytes” with no encoding information[/quote]
And what about the other drivers?
What about them ?
SQLIte has a direct and simple configuration switch that allows us to add it by setting a flag and recompiling
That alters the actual db engine
We don’t compile the other db engines - just a client - and those can already handle unicode as long as you use define encoding when reading the data back in & have configured the db accordingly.