The ListOfCountries has left me with a question.
Assume a french company saves an address with the country as “France” and sends it 20 km across the border to a German company. They open the file but on their computer “France” should be “Frankreich”, and “France” does not appear in their array of valid country names.
What is then the correct way to save and load localised strings across countries?
really depends
for UI items (labels, captions etc) that you can use a #Constant with they will be handled automatically IF there is a localized value
for “data” - not form labels captions etc - you’ll have to do some work regardless of whether you use localized strings or a db since there’s no framework support to do it automatically for you
you could use localized strings and the localized constant lookup code on
https://blog.xojo.com/2014/03/05/picking-a-language-at-runtime/
or you could do similarly with a database full of localized strings
see http://www.great-white-software.com/gws-rb-samples/DynamicLocalizations.zip
It’s data. Basically let’s say you want to load and save addresses. The country displayed should be displayed localised. So having just one array of country names will not be enough.
I guess you could use localised country names and always save and load the English one, though that seems like a hack.
A database might be a better choice.
Half-way between them a lookup table might work.
But all in all I’m not sure what the correct way would be.
I only know users in Germany don’t want to see “France”, and users in France don’t want to see “Frankreich”.
there is no single “correct” answer
depending on the total volume of data you are going to have to deal with will drive what mechanism you want to use
having only a single one with a clean set of convert to and convert from type methods would probably be an advantage rather than having several different mechanisms
but I dont have any basis to recommend one over another
what I would recommend though is if you are storing the data in a database do so in ONE consistent form and convert that to whatever display format at the point you display it (or gather it)
and the same holds true for date formats, currency values, etc
mixed formats in your data will / would be painful in a database
the one drawback to this is that a query using SQL also would need to be “translated” to whatever common language you store the data in so queries work as expected
this isnt so bad as long as there is no free form user input for SQL etc and you can intercept it and localize it before running the query
@npalardy is right, there isn’t a “right” way to do this. I have used the approach outlined in this StackOverflow answer in the past.
In essence, use a database with these tables:
Markus talks about the counry name and does not explicitely exclude other parts of the address, but these parts have to be excluded.
As an example, my name is Schwarz, not Noir nor Black nor Nero… so this have to stay as is. Same for the two Adress 1 and Address 2 fields (Building name / Street name) nor PO Box, etc.
The only thing to translate is the country name.
Now, I have some doubts… do we have to change the country name ?
If there is people who send letters (slow mail) to Far East (China, Japan, Viet Nam, etc.), do you write the address using Roman or local symbols ?
I would not localize any parts of a persons name or address
We store the ISO country code in the address data and look it up when we need to display it.
To simplify the storage we store all of the names for a single country in the same string.
eg:
en englishtext
fr frenchtext
de germantext
We then have a function which retrieves the required localisation or a default one.
where can i find a list of country in various language???
is there any other en, fr and de???