php-i18n Digest 10 Dec 2004 10:55:10 -0000 Issue 267
Topics (messages 824 through 829):
Re: Using Translation from PEAR, other libraries
824 by: Ian Eure
825 by: Christophe Chisogne
826 by: Christophe Chisogne
827 by: Michael Wallner
Locale names, was:Using Translation from PEAR, other libraries
828 by: Tex Texin
829 by: Christophe Chisogne
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Ian Eure wrote:
> - Hard to search for translated strings
> - Hard to set up
> - Not easy to use with a site that needs to store content in a database
> and translate it as well
>
I forgot one very important one:
- Apache (1.3.x at least) won't display Gettext'ed strings if it's locale is
set to 'C' (the default), and has issues if it's set differently.
--- End Message ---
--- Begin Message ---
Ian Eure wrote:
PHP's gettext was my next choice - it's the fastest - but it didn't work out
for a few reasons.
- Hard to search for translated strings
Getting strings marked as 'to be translated' with _("...") is easy
with "xgettext -k_ -L PHP ...". Then with msgmerge the partially translated
files can get recently added strings in src file. The big advantage of gettext
is its toolchain (xgettext, msgmerge, po editors etc), and translators only
have to translate txt files (no php/perl knowledge required).
- Hard to set up
With gettext php extension installed and correct path, it's not that hard
(locale/fr_BE/LC_MESSAGES/domain.mo). Only thing really annoying is that
locale names arent standardized : win uses long names like English, French etc
while *nix simply uses std names like fr_BE, en_US, nl_NL etc
Well, there is a second one. To set locale, you have to define env var
(LC_MESSAGES, LC_ALL, LANGUAGE,...) Not sure same settings work everywhere
(Unix boxes at least). But with php safe_mode on, only some env vars can
be set, which means editing php.ini is often required to fix this, like
safe_mode_allowed_env_vars = "PHP_,LC,LANG,TZ"
Perhaps a third, but I never got an answer to this one.
I dont know if using gettext with php (as Apache module) is "thread safe".
If 2 scripts are setting locale, I just hope they wont mix.
- Not easy to use with a site that needs to store content in a database and
translate it as well
I think translating content in DB simply involves adding a column for
each field to translate. Ex for a title field, adding title_fr, title_de etc
Christophe
--- End Message ---
--- Begin Message ---
Ian Eure wrote:
- Apache (1.3.x at least) won't display Gettext'ed strings if it's locale is
set to 'C' (the default), and has issues if it's set differently.
I'm interested to know about these issues.
I discover gettext uses a cache system : it sometimes requires to reload
Apache if some translated strings changed.
About setting locales, I discover that php safe_mode can forbid settings
env var like LC_ALL, which makes impossible to switch locale.
Are those the issues you talked about? If not, what are they?
Christophe
--- End Message ---
--- Begin Message ---
Hi Christophe Chisogne, you wrote:
> Ian Eure wrote:
>> - Hard to set up
>
> With gettext php extension installed and correct path, it's not that
> hard (locale/fr_BE/LC_MESSAGES/domain.mo). Only thing really annoying
> is that locale names arent standardized : win uses long names like
> English, French etc while *nix simply uses std names like fr_BE,
> en_US, nl_NL etc
This is where I18Nv2::setLocale() comes in (already used in Translation2)
> Well, there is a second one. To set locale, you have to define env
> var (LC_MESSAGES, LC_ALL, LANGUAGE,...) Not sure same settings work
> everywhere (Unix boxes at least). But with php safe_mode on, only
> some env vars can be set, which means editing php.ini is often
> required to fix this, like safe_mode_allowed_env_vars =
> "PHP_,LC,LANG,TZ"
Yeah, this is a real show-stopper :-(
> Perhaps a third, but I never got an answer to this one. I dont know
> if using gettext with php (as Apache module) is "thread safe". If 2
> scripts are setting locale, I just hope they wont mix.
Well, this only concerns threaded Webservers/Apache-MPMs (AFAIK),
but I guess it's not thread safe.
Regards,
--
Michael - < mike(@)php.net >
signature.asc
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
The language_country name model is defined in RFC 3066, and is being
updated.
It went into the hopefully final Last Call process yesterday.
The proposed version is:
http://www.inter-locale.com/ID/draft-phillips-langtags-08.html
The new version will allow for more descriptive names to provide better
coverage and more accurate designations of message text and other content.
Just fyi.
Microsoft does have a different convention, but supports the POSIX names as
well.
However the semantics of a locale are not well defined or standardized, and
so even if the name is supported, different technologies (Unix, Java,
Windows) will do different things with the same locale identifier.
There is work underway to standardize locale definitions. If interested look
at CLDR, the common locale data repository, hosted by the Unicode
Consdortium at http://www.unicode.org/cldr .
Tex Texin
Internationalization Architect, Yahoo! Inc.
-----Original Message-----
From: Michael Wallner [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 09, 2004 4:16 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-I18N] Re: Using Translation from PEAR, other libraries
Hi Christophe Chisogne, you wrote:
> Ian Eure wrote:
>> - Hard to set up
>
> With gettext php extension installed and correct path, it's not that
> hard (locale/fr_BE/LC_MESSAGES/domain.mo). Only thing really annoying
> is that locale names arent standardized : win uses long names like
> English, French etc while *nix simply uses std names like fr_BE,
> en_US, nl_NL etc
This is where I18Nv2::setLocale() comes in (already used in Translation2)
> Well, there is a second one. To set locale, you have to define env var
> (LC_MESSAGES, LC_ALL, LANGUAGE,...) Not sure same settings work
> everywhere (Unix boxes at least). But with php safe_mode on, only some
> env vars can be set, which means editing php.ini is often required to
> fix this, like safe_mode_allowed_env_vars = "PHP_,LC,LANG,TZ"
Yeah, this is a real show-stopper :-(
> Perhaps a third, but I never got an answer to this one. I dont know if
> using gettext with php (as Apache module) is "thread safe". If 2
> scripts are setting locale, I just hope they wont mix.
Well, this only concerns threaded Webservers/Apache-MPMs (AFAIK),
but I guess it's not thread safe.
Regards,
--
Michael - < mike(@)php.net >
--- End Message ---
--- Begin Message ---
Tex Texin wrote:
The language_country name model is defined in RFC 3066, and is being
updated.
It went into the hopefully final Last Call process yesterday.
The proposed version is:
http://www.inter-locale.com/ID/draft-phillips-langtags-08.html
Good to see real/authoritative informations. Thanks for this :)
I only heard about
- ISO 3166 (country names)
- ISO 639 (names of languages)
Microsoft does have a different convention, but supports the POSIX names as
well.
I tested gettext with php4 on a win2k srv. Only MS names 'French, Dutch,..'
worked, not POSIX names (fr_BE, nl_NL). But perhaps I missed something.
(I finally created copies for gettext dirs like /french, /fr_BE etc).
There is work underway to standardize locale definitions. If interested look
at CLDR, the common locale data repository, hosted by the Unicode
Consdortium at http://www.unicode.org/cldr .
Steps to standardization is good news, but not respected enough.
Ex websites using 'extended' html markup, splitting the web.
Christophe
--- End Message ---
