localization question

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Robert Dufour

    #1

    localization question

    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



  • AMDRIT

    #2
    Re: localization question

    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, localizedcaptio n
    FROM [languagesupport]
    WHERE
    localizedid = <desiredlanguag ecodehere>
    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" <bdufour@sgiims .comwrote in message
    news:OfZ6z2VdHH A.4964@TK2MSFTN GP04.phx.gbl...
    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
    >
    >
    >

    Comment

    • rdufour

      #3
      Re: localization question

      Thanks a lot
      Bob
      "AMDRIT" <amdrit@hotmail .comwrote in message
      news:uX9ldBXdHH A.4616@TK2MSFTN GP03.phx.gbl...
      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, localizedcaptio n
      FROM [languagesupport]
      WHERE
      localizedid = <desiredlanguag ecodehere>
      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" <bdufour@sgiims .comwrote in message
      news:OfZ6z2VdHH A.4964@TK2MSFTN GP04.phx.gbl...
      >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
      >>
      >>
      >>
      >
      >

      Comment

      Working...