Multi language, how to approach this?

[s_filipowicz]

Hi everyone,

I have a website on which I want to offer multi language, but no idea what is the best way to do this.

There 2 plans I have:

1:

Of course all content (text) is in a database.

If a user would want a different language, the user would click on a link/flag, this would put the requested language in a session variable, for example: session.language = "es"

In the database I would have 2 columns (every language has 1 column) and then select the text which belongs to 'es'

Every page would then do a request to the database to get the text beloging to the session.language.

PROS: Relatively simple to implement

CONS: SEO wise I don't think this could be very good. http://www.domain.com/page.cfm would give an english text or spanish text (or other language). Google will not add duplicate URL's

2:

Do something with http://www.domain.com/en/page.cfm for english and http://www.domain.com/es/page.cfm for english.

With a URL rewrite rule the language value in the URL http://www.domain.com/en/page.cfm would actually be a page http://www.domain.com/page.cfm?language=en

The url.language variable will then select the correct language from the database.

PROS: Unique URL for each language. Good for SEO and Google indexing.

CONS: A bit more difficult to implement. (I think)

Or does anyone have other / better ideas?

Thanks!!

[Owainnorth]

If I were trying to do this, I'd do the latter. Bear in mind that query and page caching will massively improve the speed of your site in this situation.

[Steve Sommers]

It depends a lot on your application. If many of the pages are marketing slicks with a lot of text, option 2 would probably be better. For an application that deals with providing transactional column reports where you're mostly translating headers and the like -- stuff like we do with our payment gateway services -- then option 1 would probably be better. There is nothing stopping you from mixing the two either -- slicks use option 2, shopping cart pages use option 1.

For option 1, my recommendation is a translator cfc that you pass your text through:

<h1>#application.translator.text("User Login")#</h1>

<p>#application.translator.text("Using the form below, enter your login credentials.")#</p>

The text function generates a hash and then looks up the language equivalent (key="EN/[hash]" or "FR/[hash]"). If not text is found, return the original text. Of course, you'll have to decide if the html mark-up for the text resides inside or outside the translated text -- both ways have pros and cons.

I prefer this way over manually assigning keys for every piece of text because this leaves code that is still readable to the programmer and easier to maintain.

[BKBK]

Option 2 is closer to how I would do it. However, it still has elements from option 1, such as using url.language to determine the language from the database. In both options, interdependence between the language versions will lead to complexity in code and in database. There are considerations you have to make in an English website, which are irrelevant in a Spanish website, and vice versa.

I would create 2 entirely separate ColdFusion applications, one in English and one in Spanish, located respectively at http://www.domain.com/en/ and http://www.domain.com/es/. Each will have its own database, based on its own language.

[Adam Cameron.]

There are considerations you have to make in an English website, which are irrelevant in a Spanish website, and vice versa.

Go on then: do tell.

--

Adam

[BKBK]

@Adam,

You and others have focussed on just one design consideration of a multilingual site, namely, localization. Don't get me wrong, there is nothing wrong with that, if it is sufficient for S.Filipowicz's needs.

However, a web site is a growing organism. (That is at least my assumption here.) There might reach a point where there are too many elements to juggle between English and Spanish. The result will be complexity. For, the translated versions are strongly coupled. If you wish to generalize the site(s) so as to restrict complexity then you should, right from the start, scale your design up for internationalization or even globalization.

A site isn't just about text. Spaniards generally expect a more conversational style than the English. Colours, graphics and presentation also come into play. For example, there is a subtle difference between how the British and Spaniards interprete images, in general, black and white or reds and blues, in particular. Layout (page, text, graphics) also differs between the two cultures.

The tried and tested software way to minimize complexity is through modularization: separation into 2 or more modules. Hence, my suggestion, 2 sites.

If you choose to go down this route, it will have consequences for your staffing. Translation won't be enough. Your site will need developers and designers with the sensibility and first-hand knowledge of each culture.

[Adam Cameron.]

You kind of mix two different considerations partially in your two options here: how to identify the language (mentioned in both points), and how the data is stored (only mentioned in the first one).

We use the second approach for identifying which language site one is on, except we use a subdomain instead of an element in the path (eg: we have es.domain.com, fr.domain.com etc, rather than www.domain.com/es/ and www.domain.com/fr/).  However I think that's neither here nor there.  The rewrite is simple to set up, and a one-off, so there's no real penalty there.

As for how the data is stored, we've got a bit of a hotch-potch depending on which text it is.  Structural stuff which is fairly static (eg: in the breadcrumbs the text saying "You are here") we have in .properties files.  Slightly more frequently "managed" text like SEO-sensitive stuff is stored in a slightly different text-file-based system, due to who maintains said content.  Other (more volatile) content still is managed via a CMS.  This is basically down to which dept manages which text (as well as legacy issues like different people having different ideas as to how things ought to be done,if I'm honest).  The text-file-based stuff is loaded once at app-start-up, and the DB-stored stuff is called as necessary (with some CF & DB-side caching depending on what it is).

The text-file-based stuff is applied to a page in the way Steve suggests.  The DB stuff is just output as per normal fetched-query content.

You might want to read up on how Java handles this sort of thing, to get a fairly coherent picture of an accepted / standardised approach to such things.  Start with http://docs.oracle.com/javase/6/docs/api/java/util/ResourceBundle.html and google "java ResourceBundle".

--

Adam