users
[Top] [All Lists]

Re: RE: [cinjug-users] Localization and I18N

To: <users@xxxxxxxxxx>
Subject: Re: RE: [cinjug-users] Localization and I18N
From: <jim_garrett@xxxxxxxx>
Date: Tue, 19 Oct 2004 8:16:14 -0400
Delivered-to: mailing list users@cinjug.org
Mailing-list: contact users-help@cinjug.org; run by ezmlm
Eric,

This is exactly what I was looking for.  Thanks for the help.

Regards,

Jim Garrett
> 
> From: "Broyles, Eric" <ebroyles@xxxxxxx>
> Date: 2004/10/18 Mon PM 04:15:47 EDT
> To: <users@xxxxxxxxxx>
> Subject: RE: [cinjug-users] Localization and I18N
> 
> Jim,
> 
> I just realized I forgot to provide you any details on how I've setup my 
> database.  The application is a document repository that has files stored on 
> the file system and the metadata in the database.  Until now this has been a 
> purely English application.  Each file (called a Resource by the application) 
> can be classified against multiple lists of criteria, including type, 
> industry, zone, product, analyst and competitor.  Each of these is contained 
> in the database in a separate table.
> 
> To internationalize this, I added a language field to each table.  The 
> language field is a char type of length 2 and it simply stores the ISO 
> language code (e.g. en, es, it, de, pt, ja).  Queries call 
> getRequest().getLocale().getLanguage() (through helper methods, of course) 
> and return only results that match the user's preferred language (either as 
> set in their browser or in a preference setting in the application).
> 
> Here is an abbreviated table scheme for the Resource:
> ID (primary key)
> Title
> Description
> Keywords
> Language
> 
> The tables for type, industry, zone, etc. look like this:
> ID (primary key)
> MapId (I'll explain this in a minute)
> Name
> Language
> 
> To map the relation between the industry and the Resource, I have another 
> table:
> ResourceID (foreign key)
> IndustryID (foreign key)
> 
> In order to avoid having a table for each language, I added the MapId field 
> to the industry table.  The MapId field simply contains the corresponding ID 
> value for the original language value.
> 
> For example, assume Industry started with the following English data:
> ID    MapId           Name                    Language
> 1     1               Aerospace               en
> 2     2               Automotive              en
> 3     3               Electronics             en
> 
> Then when I add a new language (say Spanish), I would add three new rows as 
> follows:
> ID    MapId           Name                    Language
> 4     1               Aeroespacial    es
> 5     2               Automotor               es
> 6     3               Electrónica             es
> 
> Where the MapId corresponds to the ID of the original language value (i.e. 
> since Aerospace has an ID of 1, the Spanish translation of Aerospace has a 
> MapID of 1).
> 
> Then in my queries where I used to use the ID field, I know use the MapID 
> field, which ensures that if I'm dealing with a Spanish Resource, I will see 
> the Spanish industries.  This ensures that when making a mapping between the 
> ResourceID and the IndustryID I'm still using the primary key, so my 
> constraints are still intact.  Perhaps a better solution (from a database 
> standpoint) would be to make the primary key of the Industry table be an 
> aggregate key composed of the ID and the language.  But I like to keep my 
> primary keys simple (for better or for worse).
> 
> Thus far, this model has been working pretty well (though I'm not in 
> production yet, as there is other development still underway).
> 
> Eric
> 
> -----Original Message-----
> From: jim_garrett@xxxxxxxx [mailto:jim_garrett@xxxxxxxx] 
> Sent: Monday, October 18, 2004 15:12
> To: users@xxxxxxxxxx
> Subject: [cinjug-users] Localization and I18N
> 
> 
> I have a question I was hoping someone has done before and can provide some 
> guidance.  I have a customer who wants to be able to display data fields and 
> their values in the correct language when using a web interface.  I am very 
> familiar with how to localize the text fields, but the actual data, that 
> comes from the database, is a completely different animal.  I would assume a 
> different table must exist for each language to be displayed; and I assume a 
> person would have to translate the text manually that is stored in the table.
> 
> Has anyone encountered this type of requirements before?  If so how did you 
> solve this problem.
> 
> thanks in advance
> 
> Jim Garrett
> 
> 
> ---------
> You may unsubscribe from this mailing list
> by sending a blank email addressed to: users-unsubscribe@xxxxxxxxxx
> 
> --
> Find additional help by sending a blank email
> addressed to:
> users-help@xxxxxxxxxx
> 
> 
> ---------
> You may unsubscribe from this mailing list
> by sending a blank email addressed to:
> users-unsubscribe@xxxxxxxxxx
> 
> --
> Find additional help by sending a blank email
> addressed to:
> users-help@xxxxxxxxxx
> 
> 


<Prev in Thread] Current Thread [Next in Thread>