Hy Steven,
when using database-access for I18N our Zend_Locale should of course use
Zend_DB and not self-code a database access.
That's the idea of having several modules for several surposes.
Additional Ideas which we use in our I18N are for example :
- automatic language recognition
We recognize the language set by the Browser and can display the right
language on the fly.
For example: In the browser the definition is 'fr; q=1.0, en; q=0.5'
when we have an french (fr) translation we set standard to french as it is
set 100%.
Otherwise we will set the en language which is set 50%.
When we dont have eigher french nor english, we will display the language
our application was programmed in (german).
A nice feature which could be added to Zend_Locale or Zend_Client
Of course our user can set an other language he wishes everytime and
everywhere in the application
- Text-Source
A text-based (Text-Database) or CSV-based source for language files could be
good for users which dont have access to
PDO or gettext. Text-/CSV-files are good for Translation teams as they often
have problems with XML Files.
- Conversion
Convert from one locale in another.
For example a given input date/time to a defined in an other language.
$input = '18.06.2006 13:05:00.204';
$output = $I18N->ConvertDate('18.06.2006 13:05:00.204',fr-FR); // Output
would be i think '2006/06/18 01:05:00PM' for example
This is a nice feature when for example having to save always in a defined
language or format.
- Unicode
Of course we should be aware to use unicode source files, as we otherwise
would have problems with
our friends from asia as they are using extendes charactersets.
@Jason:
I didn't found the FAQ i read about from you. Where is the button to apply ?
:)
ok, that's it for now...
Maybe later for some new ideas.
Greetings
Thomas
----- Original Message -----
From: "Steven Van Poeck" <
[hidden email]>
To: "Thomas Weidner" <
[hidden email]>
Cc: <
[hidden email]>
Sent: Thursday, May 25, 2006 2:41 PM
Subject: Re: [fw-general] I18N
> Hi Thomas,
>
> I very much like the idea of the basic structure you're proposing for i18N
> :)
>
> I believe Jayson called upon people interested in working together on a
> i18N project for the ZF:
>
http://www.zend.com/lists/fw-general/200605/msg00787.html. I definitely
> think you should apply :)
>
> Just one small note on the wrapper and sources: for database access, it
> should use PDO.
>
> Best regards,
> Steven Van Poeck
>
http://poekie.free.fr>
> Thomas Weidner a écrit :
>> Hy,
>> as I mentioned befor, a I18N or L10N core is essential for building huge
>> web apps.
>> Therefor let's talk a little bit to get this baby running :)
>> I see it from the practical side as i developed an corporate application
>> which we are selling. There are much points we have to cover with I18N,
>> and each FZ-user has other needs of it.
>> I read the thread Johannes mailed me... but the theme seems to be felt
>> to sleep already as there are no mailings 'till over 1 week.
>> Let's Summarize what a I18N-ization with our ZF should do :
>> Essential for I18N seems the following
>> - Wrapper
>> - Lightweight/Fast
>> - Different Sources
>> - Different Targets
>> Lets go to detail:
>> - Wrapper :
>> The Framework MUST be a wrapper for the different Localization Mechanism
>> we need.
>> Our approach has to be, that changing the mechanism should be as easy as
>> it could be.
>> For example : $I18N = new Zend_Locale();
>> $I18N->Local('GetText',de_DE);
>> Changing the translation mechanism could also be done afterwards.
>> $I18N->Translate('write something'); // All would be translated to
>> german
>> $I18N->Local('SQL',en_EN); // We change our mechanism to SQL
>> Database and the standard language to english
>> $I18N->Translate('write something',de_DE); // we override the standard
>> language with our temporary language
>> Also the Module has to recognize other charactersets as input
>> echo $I18N->Translate('Daß ist mein öffentlicher Text');
>> - Leightweight/Fast
>> From the practical side...
>> Our Application has 0,5Mio different String. Also when we have an
>> webserver with more than 1000 People requesting sites in different
>> languages, speed is essential.
>> Leightweight means also that it has to be as simple as possible for the
>> ZF-user to use it in his scripts.
>> -Different Sources
>> As mentioned befor it is essential to have different translation
>> ressources.
>> There should be:
>> GETTEXT, XML, SQLite, MySQL, MSSQL, and maybe several others I don't know
>> until now. :)
>> Even when gettext is not threadsave as i read, it's used very often.
>> - Different Targets/Goals
>> The CLDR Project seems to me a good approach for defining a complete
>> LOCALE.
>> Take a look here
http://www.unicode.org/reports/tr35/>> Zend_Locale should not only define a translating language, but also Date,
>> Time, Measurement, Collations and so on...
>> The definition should be done in 1 class (Zend_Locale).
>> The other Classes could derive from them.
>> For example:
>> Zend_Locale_DateFormat
>> Zend_Locale_MeasurementFormat
>> When defining a date class the usage could be
>> $I18N = new Zend_Locale();
>> $I18N->Local('SqLite',de_DE);
>> $date = $I18N->Date($inputdate); // Using Standard date for de_DE
>> $time = $I18N->Time($inputtime,de_CH); // Using temporary timeformat for
>> location de_CH
>> or
>> $I18N = new Zend_Locale();
>> $I18N->Local('SqLite',de_DE);
>> $date = new Zend_DateTime();
>> $time = $date->Time($inputtime,de_CH); // Using temporary timeformat for
>> location de_CH
>> That where my thoughts until now...
>> So let's discuss about it
>> Greetings
>> Thomas
>>
>>
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.394 / Virus Database: 268.7.1/347 - Release Date: 24/05/2006
>
Locked
