This makes me think of something that has been mentioned at various times: couldn't we have a "default" version (which would happen to be in english for core) and english as just one translation, which would happen to be empty by default for core, returning the default version ? This seems to be along the line of what you suggest by "english translation", and would nicely fit in the overall localization scheme by not supposing contrib modules, for instance, are by default written with english text, but could have english as just one location, and the default distribution would be just that: default. There's no code involved, just a documentation choice, so it is in time for D6. The language code for default would only have to be anything different from the ISO 639 values (anybody for "@@" ? it sorts before any other alpha value). ---- Original Message ---- From: kkaefer@gmail.com To: development@drupal.org Subject: Re: [development] String freeze Date: Tue, 3 Jul 2007 10:17:59 +0200
Hi,
Last release, we had a "string freeze" once we hit RC1. This meant
that any clarifications/clean-ups/etc. to any user-facing text (help messages, form labels, etc.) were 'frozen' and couldn't be altered after RC1 was released, in order to give translators ample
time to translate Drupal.
I'm all for a string freeze like the last time. Keeping the string freeze date in mind helped us get a lot of UI text fixes in which improved overall usability.
b) Is RC1 enough time? If we set it at beta-2 or something would that allow us to include a few translations in Drupal core itself by RC1?
I am a translator as well (German translation) and I think it was enough time to complete at least the most important parts of it.
I'd like to propose something else, though: While translating, I get
to read all the help text included in Drupal, and I noticed that most
of those help texts are not very well written and even include factual errors (e.g. removed features, no mention of newly added features etc.). I'd like to cast a kind of "user interface text team"
that especially takes care of such issues. We could for example set up a site with Drupal 6, enable locale module and use it to modify the english strings (english -> english "translation"). After we've fixed those strings, we can create patches against HEAD. Not sure if
that's a good/practiable solution. Any suggestions?
Konstantin Käfer http://kkaefer.com/
On 7/3/07, FGM <fgm@osinet.fr> wrote:
This makes me think of something that has been mentioned at various times: couldn't we have a "default" version (which would happen to be in english for core) and english as just one translation, which would happen to be empty by default for core, returning the default version ?
In the past there has been severe performance implications when the locale module was enabled. Sites suffered heavily from excessive queries. I am not sure if this is still the case, but since all of sites I do are English, I would not want to go that route for performance's sake. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
participants (2)
-
FGM -
Khalid Baheyeldin