British English "Translation"

  • Steve Rogerson

    Steve Rogerson - 2005-11-20

    I would like to create a British English version of the system. (eg spell catalog catalogue), but this poses a slightly different problem to most translations in that the the "locale" code is restricted to the iso530-1 list of languages. So "en" for example. I really need the the full version of the locale "en_GB", with the base being "en_US". As far as I can see this only involves renaming that directory en -> en_US, amending language_list.php and  changing the update process to change en to en_US.

    I am happy to do this, but as it hits the core, I guess it would be nice if I got some kind of approval from the powers that be.

    I could just en_GB as a locale in the short term, but it seems to me that the earlier that this is resolved properly the better.


    • Hans van der Weij

      Approval will have to come from the development team, which I'm not part of, but I do have some information on this:
      1) This is not the first time locale issues are brought up. Search the forums for more information en certainly do check this bug report:
      2) For the development team time they can spend on OpenBiblio is currently very limited, so it could take a while to get a reaction.

      Is this answer sufficient for now?

      • Micah Stetson

        Micah Stetson - 2005-12-14

        Thanks for covering for us Hans, and not just on this thread.  We owe you.

        I don't have any problem with a locale named en_GB, or anything else for that matter.  Dave could overrule me on this, but short of a pronouncement from him, en_GB, and other lang_COUNTRY locale names have full official approval.


    • Steve Rogerson

      Steve Rogerson - 2005-12-16

      I'm Ok with adding en_GB, BUT, this contradicts the comments in the languge_list.php and what is really required is to rename the "en" to "en_US".

      We question is not really about adding en_GB, but making the changes to "en" and language_list.php. Then, of course also a conversion problem for existing dbs and changing the "locale" of existing translations.

      If this was done then the fix mentioned above would be redundant as "locale" would really be "locale" ( ok not really, but the char set is seperately stored, so it sort of is).

      • Hans van der Weij

        1) I think it is better to make the locale selection mechanism for the install process work like Admin: Library Settings, removing the need to edit language_list.php when a new locale is added.
        OpenBiblio version 0.5.0 introduced a new mechanism for Admin: Library Settings, the descriptive name for a locale is parsed from /locale/[locale_name]/metadata.php, but the current version install process still uses language_list.php.

        2) Locale naming problems
        Would it be OK to promote renaming the locale directory to match the system locale name as an intermediate solution for users, until a universal solution exists?

        3) Locale for Netherlands / Dutch
        In addition to comments of other users on other discussion threads I can confirm that the 2 character language code standard which language_list.php refers to, is not correct for a universal solution. My Windows testing system needs locale name for the Netherlands / Dutch language to be nld, and not nl, nl_NL, etc.
        Requirements for Linux production system unknown, but nl is also not correct.

        • Micah Stetson

          Micah Stetson - 2005-12-17

          1) Eliminate language_list.php
          That's where I want to go, too.  In actuality, I want to make metadata.php contain a class that can define functions as well.

          2) Encourage directory renames temporarily
          That is not a bad idea for an intermediate solution.  If somebody can get (1) done soon as a patch against CVS, then I can include it in version 0.5.2.

          3) System local names not universal
          Having to deal with the different system locale names is a pain.  Besides, I have yet to get the localeconv() stuff working correctly on any of my Linux or BSD systems, and I'm en_US.  I would think that would be one of the easiest locales to get going.

          As a long-term solution, I'm thinking it might be worthwhile to forget about the system locales and do things on our own.  What this means is that authors of translations will need to provide their own formatting functions for numbers, money, and dates.  Two of the functions for en_US could be something like this:

          function moneyFmt($num) {
            return '$'.number_format($num, 2, '.', ',');
          function dateFmt($timestamp) {
            return date('d/m/Y', $timestamp);

          Pretty simple, but I'd like to know if any of the translators think this would add a significant burden.  Most translations could probably just copy and paste the relevant code from an existing translation.


          • Antonio

            Antonio - 2005-12-17

            I definitely encourage NOT depending on the system locale information.  In my case, I am running OpenBiblio from a US server but I need everything to be in Spanish and with Latin American dates but to use US dollars (which is the official currency in Ecuador).  So I had to program around the locale info anyway.

            • Micah Stetson

              Micah Stetson - 2005-12-17

              That's something I hadn't thought of, and another good reason to ditch localeconv().


          • Hans van der Weij

            1,2) Patch posted at
            Patch tested OK with locale name en_GB, so lang_COUNTRY locales should be no problem.
            Correcting afterwards is possible in 3 steps:
            change Library Settings, rename locale directory, change Library Settings.
            Examples from my Windows testing system:
            /nl/ renamed /nld/ moneyformat correct for Netherlands
            /en/ renamed /uk/ moneyformat correct for United Kingdom

            3) I think translators / system administrators / users will be happy when these suggestions are implemented some day.
            It is better to have a flexible mechanism that we can understand and manage with some effort than to depend on something inflexible which would have to be enhanced further anyway.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks