[development] String freeze

[FGM]

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 at gmail.com
To: development at 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/
>
>