Slashdot Mirror

← Back to Stories (view on slashdot.org)

Locale Data Markup Language Version 1.0 Released

Posted by Hemos on from the making-it-work-for-everyone dept.

Ram Viswanadha writes "The Free Standards Group Open Internationalization Initiative (OpenI18N) announced the release of the locale data markup language specification (LDML), Version 1.0."

2 of 13 comments (clear)

  1. Half of the work by Matthias+Wiesmann · · Score: 3, Interesting
    I think this is a good initiative, having a single scheme to describe locales can only push for better localisation. One place where this could be very usefull is for web sites. If you could simply upload your locale to web site to get a personalised display it would really be a nice.

    One thing that I'm not convinced of is that those locale merge two things: how data is displayed (number, data and currency display), but also how certain words a translated, yes, no, name of days etc... I would prefer to keep both things separated. I tend to use applications with an english localisation, but with number and dates in my locale (swiss french).

    I suppose I could design my own locale, but I think translation should be handled in the application's localisation part. If not, you will get mixed results. I have seen to many dialog boxes asking

    Do you want to save?
    [Oui] [Niet] [Abbrechen]
    I find the idea of Europanto funny, but I would prefer avoid it in user-interfaces.

    This said, I fear the core problem is not so much the lack of standard, but the fact that application often have text and date behaviour hard-coded, or hard-linked to the localisation (like Apple's mail.app)

    By the way, am I the only person that finds it ironic to see the following code in the header of the specification?

    <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
    <meta name="ProgId" content="FrontPage.Editor.Document">
    1. Re:Half of the work by PhilipMatarese · · Score: 3, Insightful

      Hard coding strings is a big problem when it comes to localizing. If I write an app with a strings file containing every word to be displayed:
      First, it make maintenance easier. The client sees the demo, and says "we don't call it a username, we call it a login!" or something like that. You just change any strings with username in them to have login in them instead.
      Second, you can easily update the language for an International version of the app. Or you can have a directory with several language files and choose which one to use based on preference settings (I think this is pretty common).

      I think problems with date/currency type things stem from programmers not using standard packages and methods to deal with these types. For example, I don't want to use a date format object, so I just print day+'/'+month+'/'+year.

      I say better localization is always good.

      Maybe we could use this to replace 's' with 'z' in localisation, while reading Slashdot in the US.