Re: Localization Structure Model

[Joakim Ziegler <joakim helixcode com>]

On Thu, Nov 16, 2000 at 05:57:32AM +0300, Cleber Rodrigues Rosa Junior wrote:

> Things that are translatable, and very often referred to, such as the
> description of an application in the application list, should be stored in a
> database. The parsing script would then fetch the entry depending on user's
> language selection, falling back to a default one (english for www.gnome.org,
> swedish for www.se.gnome.org and so on) in case a translated entry doesn't
> exist. This approach would give us some (partly) localized sites in very
> short time. Note that this give us freedom to keep all original+translated
> text in a single database or split them across the world. The script would
> have to know about this, though. Example:

>   -> A single, centralized database:
>   SELECT description FROM applist_<$LANGUAGE> WHERE code = XXXX.
>   A simple dynamically modified SQL statement like that would do.
>   -> Some languages here, some there:
>   We mantain a list of languages/hosts running database servers and then
>   the script would decide where to get the data.

>  $DBServersList = { en => dbserver.gnome.org; pt_BR =>
>  sapience.myserver.com.br }
>  and then the connection to the server would be based on that.

> This way we could have more or less real mirrors, and still achieving (some
> level of) localization with mininal effort. I don't know about the actual
> process of fiddling with this kind of data in the gnome website, but there
> could be a frontend to this. People like Ralph Muldoon might want to put
> something like this together.

This is one possible way of doing it, but I think it's a little
overcomplicated. There are several reasons for this, and I think they're
worth mentioning here, not as criticism of your idea, primarily, but as
general things to think about.

1) Putting normal page content in SQL sucks for a number of reasons. It's
  slow, it doesn't have the revision control advantages of CVS, people have to
  have a local database set up to test even simple pages locally, etc.

2) SQL connections over the network are a bad idea, just because of the
  latency, and because people don't want to leave their SQL daemons running
  able to accept connections from the outside world.

In general, I'd like to avoid SQL as much as possible. On sites like
www.gnome.org, which get massive traffic, it's a hog. We should use as many
flat files as possible, and where we use SQL, we should use cache files for
the overview pages and other often used parts of the site.

Now, localizing appindex entries is a separate issue, but for localizing
general page content, the best thing to do if we're using PHP is probably
defining some functions like l10n_text_start(language) and
l10n_text_end(), and put blocks of text between pairs of these functions.
It's then really easy to pick the right one, since l10n_text_start just
checks if language is the same as the current language, and if not,
suppresses the output.

-- 
Joakim Ziegler - Helix Code web monkey - joakim helixcode com - Radagast IRC
      FIX sysop - free software coder - FIDEL & Conglomerate developer
            http://www.avmaria.com/ - http://www.helixcode.com/