Managing larger amount of localized data

Question

Hello!
(This is a bit long and maybe fuzzy, it's 1:30AM here)
I have this idea about making a webapp with (among other things) three drop down lists where people can select;
* country
* state
* city
That is quite easy to solve.
After someone for example selects "Canada" as country I have a JavaScript to pull some xml/json from my web-app with all the states of Canada.
Same thing happens when they select a state, I get a list with cities within the state.
However, here comes the tricky part:
I want to localize the countries/states/cities in english, french and spanish (and possibly more later, portugese).
Suddenly I have a load of new data to manage and I have no clue how to structure this in a good way. :(
First I thought I put everything in arrays in a servlet, but that results in huge classes and not all data needs to be in memory all the time.
Second I thought I put the data in a database and structure it up in 3 tables (countries, states, cities) but then I got stuck on how to make a good table structure which is manageable with TopLink/EclipseLink.
Example:
CREATE TABLE countries
countryid CHAR( 2 ) NOT NULL, -- 'us', 'mx', 'ca'
locale CHAR( 2 ) NOT NULL, -- 'en', 'fr', 'es'
countryname VARCHAR( 64 ) NOT NULL,
CONSTRAINT countries_id_pk PRIMARY KEY ( countryid, locale )
CREATE TABLE states
stateid INTEGER NOT NULL, -- same for same state in different locales
countryid CHAR( 2 ) NOT NULL, -- 'us', 'mx', 'ca'
locale CHAR( 2 ) NOT NULL, -- 'en', 'fr', 'es'
state VARCHAR( 64 ) NOT NULL,
CONSTRAINT states_id_pk PRIMARY KEY ( stateid, countryid, locale )
... and so on..
The above examples is a pain to deal with due to the JPA idea of using embedded classes for composite primary keys. It becomes much juggling with objects there :(
I also need a method to reliably generate seqence numbers for 'stateid' which are the same across languages, and I haven't found a method in JPA which allows me to generate sequence number when I want to. :(
Or is there a better method to organize the data?

Answer 1

apalsson wrote:
jschell wrote:What is huge?Putting all countries, their states and the states all cities as constants in a class file.
It's going to be a very large class which also contains data not necessary all the time.
I doubt that is going to happen. For starters it is unlikely that your market supports that and even less likely that your application does.
Not to mention that maintaining that for the entire world might just possibly be a full time job.
And it still probably doesn't take that much space. After all 1 meg can hold 13,000+ 80 character values.
>
That is a bit problematic.
There are two sides: user data and storage.
For displaying the names you need something to pull the data from. If you want to localize then you will need a localization value.
>
I am using two methods to select the locale, first is by user preferences and the second is what language is configured in their www-browser.
To select a country I use the ISO-standard name ("mx", "ca" or "us") and then depending on what locale the user has selected it can be "Mexico" (for "en" locale), "México" (for "es" locale" or "Mexico" (for "fr" locale).
MIght want to be careful with that. If I am in Arizona and running a shop with employees who principal language is spanish-mexican I don't want to have to specify that my country is Mexico, because of course it isn't.
{quote:title=jschell wrote:}
There are business drivers though. Have you considered what happens when there is a name change? The names do change. If you print a report for a year ago should it display the new name or the old name? A new name means that the report doesn't match what you printed a year ago. A old name might really annoy someone. Might even be illegal.
{quote}
True. That is why it is easier to have the data in a database instead of hardcoded in a class.The fact that it is in a database doesn't change what I said.
My problem is how to organize it though. It's giving me a headache but now I realize that my question should really be asked in a database forum and maybe not a design pattern forum. :)It is a data problem not a database problem. Your data model drives the persistence model.