----- Original Message -----
From: "Jeff Dairiki" <da...@da...>
hi jeff,
> >I agree 100% with you, while I can see the point on using gettext with
> >a languaje like C, I still cannot see the point on using gettext on
> >a languaje like PHP.
>
> Not that I'm completely sold on gettext either, but one big advantage
> of using gettext (particularly for developers/translators who use emacs)
> is the ability to use the GNU gettext tools to do things like
> find new strings to be translated in (changed) source code, and
> merge those new strings into the translation (.po) files.
this can be done with a simple perl script I suppose...
> Note that PhpWiki _should_ (is designed to) work even if
> PHP was compiled without gettext support. If it doesn't, that's
> a bug. Report it.
well, the fact is, I do have php with gettext support,
but with the recent gettext changes, php changes and so on
I ended up with a semi-working gettext support in php
and I reported my problem to nalin at redhat who confirmed
the problem...
and the fact is that a dictionary-based translation Just Work (tm),
translations with gettext, work if you are lucky...
> >a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
> >(ie. the client browser languaje) ... is IMO better ...
>
>
> 1. You wouldn't want HTTP_ACCEPT_LANGUAGE to affect the default
> pgsrc.
>
> 2. Since the page content of a particular wiki are (most often)
> primarily in one language, there's not a whole lot of point
> in allowing the viewer to select various languages for the
> templates/dates...
yeah, that may be a problem, but the root problem is that there are
different templates for every languaje, and *that* is what is wrong
IMHO...
and another thing that is wrong is that phpWiki treat english like
a special languaje, there is no need to, "en" should be in locale
like everybody else...
/sergio
|