Bastien Koert wrote:
> No, as all of our users have to authorized to use the app, we store
> the desired language in a field in the user record. However, we also
> supply functionality via a drop down to allow the user to change the
> language if desired.
Okay, that's very similar to my approach. For first-time users (of
which I will have a lot), the language is set by their browser's
language setting. Most users won't be changing it.
> I agree its difficult to separate the language and the code, but if
> you create xslt / html files for each language then its a much simpler
> matter, and far less resouce intensive, to direct the user to that
> page in their desired language.
I leave that to Apache and the 'prefer-language' environment variable -
I guess my main issue is to do with e.g. error-messages from PHP code
("please complete this field correctly" etc) and from javascript ditto.
I guess for error-messages, it's back to gettext(), which does make some
sense.
> Again, you and just use PHP and handle the labels and option (drop
> downs, radios etc) variables in real time but I never see the point
> in doing the same thing over and over again when its much cleaner (if
> more management intensive) to direct the user to a static resource
> and pass in an XML string with the data in it.
Totally agree.
> At work, we don't use gettext() since :
> a) its an classic ASP shop ( :-( ), therefore no Linux and no PHP
Ah. :-)
> b) the db current doesn't support multi-byte charsets
>
The gettext db doesn't support UTF8??? Uh oh, that's a show-stopper.
/Per Jessen, Zürich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
