in reply to i18n best practice

I'm trying to figure out the least insane way to have multi language support on a project I'm doing.
Perhaps you should be telling a bit more what your project is about, and what you what your goal (relating to translations) is. Will you have static data? Dynamic data? A few languages? Many languages? Are you going to provide the translations yourself? Hire translators? Rely on volunteers? Use Babelfish? Once the coding is done, is that the end of translations? Will the coding ever be done, or this an internal evolving project? Do you have long sections of text, or are we talking about templates that need translations for tags?

Replies are listed 'Best First'.
Re^2: i18n best practice
by jmo (Sexton) on Mar 16, 2010 at 17:04 UTC

    There will mostly be static templates, with dynamic data not being a real problem (titles of records and books).

    Initially I'll only need one language as I'll see if anyone but me finds the pet project useful or not. But hopefully will I need to translate to one or two languages at least. As it's a no-money-gain-server-in-my-closet type of project will it either be volunteers or myself (I suspect you have noticed English isn't my native language) at least to English and then hopefully with the help of someone enjoying the site being better at it.

    The templates do/will contain a bit of text and all menus, buttons etc will as well. All in all not massive amounts but I hope to learn some from this as well when/if I need to do it on a larger scale.

[reply]

      The only experience I have this was for GUI interfaces not web pages, but we found very quickly that it was better to use a separate resource (the GUI equivalent of a template) for each language, than lots of individual strings. The problem being that saying the same thing in different langauges can mean the length of the strings vary enormously, which makes layout a pain.

      It's probably less of a pain with web pages as HTML is more flexible, but there are other considerations too. Eg. Different countries perceive colors differently according to their cultural references. I can't remember which, but one country had a real problem with there being any red on a page. It was far easier to accommodate such preferences by having a separate template for each.

      The only other piece of advice I'd offer is that you get your translations done by one native speaker and verified by another independant native speaker. We had some done by a second language translator and the results were more than a little embarassing.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

        Somewhat disappointing but I suppose that's the way it is, I've been working at a company having the same code base for several countries and that's how they where doing it, one template per language. A bit disappointing but when also considering layout and colours it makes sense.

        Oh well, was hoping for a silver bullet here but I guess as long there are no werewolves one should be content.

[reply]

In Section Seekers of Perl Wisdom