Re: [Phpwiki-talk] About languages

[Jeff D. <da...@da...>]

On Wed, 28 Nov 2001 10:08:36 +0000
"Lawrence Akka" <la...@20...> wrote:

> A few thoughts -
> 
> 1)  The language of the interface should be user-selectable.  Just
because 
> the [web|wiki]master has decided to set the locale as Italian, doesn't
mean 
> that everyone wants to see Italian links/instructions.

Yes, once we have real users and user preferences, that's probably a fine
idea.
 
> 2)  Is gettext the best solution for Multi-languages?  It requires php
to 
> be complied in a particular way.  Not everyone can specify how php is 
> compiled.

One of the big advantages of using gettext is the development tools that
are available for it.  (I.e. there is a program which scans through all
the source code and pulls out strings which are used as arguments to
gettext; another program merges any changes in that set of strings with
the editable translation map (.po) files; and there's a po-mode for
emacs.)

PhpWiki does not require gettext support to be compiled in to PHP.  It
provides a pure PHP replacement if it's not.  (I haven't tested that in
awhile, so it may well be broken...)

The only downside I see is that one is required to have the gettext tools
installed (and have some idea of how to use them) to be able to edit or
customize the translations. 

We need to use the standard setlocale() stuff anyway to get date formats
right.  Gettext is the natural way to handle translated strings.

>     define ('_MUST_BE_AUTH', 'You must be authorised to do that');

This is a nightmare to maintain.  Imagine:

  In somefile.php:
      $msg = sprintf(_MUST_BE_AUTH_TO_EDIT, $pagename);

  In somelang.php:
      define ('_MUST_BE_AUTH_TO_EDIT', "Ogg frrble MOTU erg '%s' frk.");

  In deflang.php:
      if (! defined('_MUST_BE_AUTH_TO_EDIT'))
           define ('_MUST_BE_AUTH_TO_EDIT', "You must be god to edit
'%s'.");

The gettext development tools handle all this for you.

> Another problem with gettext is that if you mistype the original
> language in the code (and some of the phrases are quite long),
> gettext is unable to find the translation.

If/when the language becomes user selectable, I think the selection will
be made via a <select> field in a <form>.  (The local admin will have to
make sure the the choices presented are all valid on the local system.)

On the administration side: it is very confusing to figure out which LANG
settings work on a particular system.  We should probably code in a list
of alternatives to try for each language which PhpWiki supports.  I.e. in
the config file, the admin sets $LANG='german'; the php code then tries
LANG='de_DE.ISO-8859-1', LANG='de_DE', LANG='de', LANG='deutsch',
LANG='german' until it finds one which works.

> 3)  It seems to me to be asking for trouble to have to translate the 
> templates for each language.  Each time the template changed, the 
> translations would have to be updated.  Wouldn't it be better to have 
> language defines (as above), or even template variables in the template,

> which are replaced by the Template munger appropriately, eg:

Yes.  Good idea.

This can more-or-less be done now (in 1.3), in an ugly fashion, as
follows: 

   <a href="http://..."><?php echo gettext("Some text."); ?></a>

Perhaps we could support a more compact syntax...


And while on the subject, my one nit about gettext is:

For it's compactness, I much prefer 
   $msg = _("string");
to
   $msg = gettext("string");

The _() abbreviation is standard usage --- the gettext tools support it by
default.  (PHP, if gettext support is compiled in, supports the _() syntax
already.  We'd have to define the '_' replacement function when there's no
PHP gettext support if we were to start using it in PhpWiki code.)

Does anyone have objections to the abbreviated syntax?