localization question

  • Thread starter Thread starter Robert Dufour
  • Start date Start date
R

Robert Dufour

In an english only application, it is fairly easy to make the table and
field names in your application descriptive so that on creating the
interface, most tools that bind data take the default field name and put it
as the column name in say a grid control.

However if you have a multi lingual UI you can localize the UI in Vs 2005 by
selecting the language of the form and changing the text property of the
controls to the localized text. So getting a localized form for a language
is fairly easy, although time consuming.

HOWEVER a problem crops up for the user who needs to be able to use a
reporting tool and having access to the tables, finds descriptive field
names in English only when he/she is a french speaker and use the french
localized version of the app.
Say he/she normally sees a form tellingh him he is looking at "la liste des
clients" and field "nom du client", but when he looks at the database
through his reporting tool he finds no table clients, in english its
Customers and no field "nom du client" , in english its "Customer Name". He
/she therefore needs to work out what the french, german or italian field
name he sees in the UI relates to the english table names and english field
names he sees in the tables. For some users this may be quite difficult. I
am thinking in the context where you have users of a centralized database
and in this group of users some use one locale , say english and others use
french for instance. In addition if he/she wants a report with French column
headers, he/she will have to go in the report generator and change default
column headers because usually the lables will use the name of the database
field. So this imposes a lot of additional work on end users - not good.

I am not concerned with localizing the CONTENT of the database fields that
need to change depending on the locale being used, basically you have no
choice but to put localized content in your database fields for each
language being handled and that's fine I know how to handle that.

I am sure many developpers have had to deal with this problem and I wonder
if there is a way somehow automate this translation of table names and field
names for users who need to create on the fly reports in languages other
than the database default language.

Any insight in how to most effectively approach this problem would be
greatly appreciated.

Bob
 
One method that I have used and seen employeed else there is to have a
resource transaltor for descriptive titles. For example, the database was
desinged in English but is to support French and German speaking users. I
add a table to the database that represents replacement strings for database
columns and tables.

Prior to populating a list or layout selection, I would exchange the
English captions for the desired ones. i.e.

SELECT
id, caption, localizedcaption
FROM [languagesupport]
WHERE
localizedid = <desiredlanguagecodehere>
and source = 'name of known table, view, or stored proc'

it becomes tedious to maintain this list after a series of iterations of the
schema and so I usually add version support to the table as well.

and schemaversion = <application's current release version>

Now the DBA can work nativly with the schema, the translators can keep
everything current, the developer is unconcerned and the user is less
irritated.
 
Thanks a lot
Bob
AMDRIT said:
One method that I have used and seen employeed else there is to have a
resource transaltor for descriptive titles. For example, the database was
desinged in English but is to support French and German speaking users. I
add a table to the database that represents replacement strings for
database columns and tables.

Prior to populating a list or layout selection, I would exchange the
English captions for the desired ones. i.e.

SELECT
id, caption, localizedcaption
FROM [languagesupport]
WHERE
localizedid = <desiredlanguagecodehere>
and source = 'name of known table, view, or stored proc'

it becomes tedious to maintain this list after a series of iterations of
the schema and so I usually add version support to the table as well.

and schemaversion = <application's current release version>

Now the DBA can work nativly with the schema, the translators can keep
everything current, the developer is unconcerned and the user is less
irritated.


Robert Dufour said:
In an english only application, it is fairly easy to make the table and
field names in your application descriptive so that on creating the
interface, most tools that bind data take the default field name and put
it as the column name in say a grid control.

However if you have a multi lingual UI you can localize the UI in Vs 2005
by selecting the language of the form and changing the text property of
the controls to the localized text. So getting a localized form for a
language is fairly easy, although time consuming.

HOWEVER a problem crops up for the user who needs to be able to use a
reporting tool and having access to the tables, finds descriptive field
names in English only when he/she is a french speaker and use the french
localized version of the app.
Say he/she normally sees a form tellingh him he is looking at "la liste
des clients" and field "nom du client", but when he looks at the database
through his reporting tool he finds no table clients, in english its
Customers and no field "nom du client" , in english its "Customer Name".
He /she therefore needs to work out what the french, german or italian
field name he sees in the UI relates to the english table names and
english field names he sees in the tables. For some users this may be
quite difficult. I am thinking in the context where you have users of a
centralized database and in this group of users some use one locale ,
say english and others use french for instance. In addition if he/she
wants a report with French column headers, he/she will have to go in the
report generator and change default column headers because usually the
lables will use the name of the database field. So this imposes a lot of
additional work on end users - not good.

I am not concerned with localizing the CONTENT of the database fields
that need to change depending on the locale being used, basically you
have no choice but to put localized content in your database fields for
each language being handled and that's fine I know how to handle that.

I am sure many developpers have had to deal with this problem and I
wonder if there is a way somehow automate this translation of table names
and field names for users who need to create on the fly reports in
languages other than the database default language.

Any insight in how to most effectively approach this problem would be
greatly appreciated.

Bob
Click to expand...
Click to expand...
 
Back
Top