Localization Structure Model

[Cleber Rodrigues Rosa Junior <cleberrrjr bol com br>]

I was thinking about the problem we have before us, and regarding all things brought up
until here, and came up with the following (very rough) idea:

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.

Just rough... maybe dumb... ideas
Let me know what you think.