Menu
▾
▴
phpwiki-talk
|
From: Lawrence A. <la...@20...> - 2001-11-28 10:10:28
|
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.
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. What about a file with defined constants, eg:
define ('_MUST_BE_AUTH', 'You must be authorised to do that');
We could then translate the file for each language, and include the
appropriate one, depending on the user's selection. 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. Perhaps the answer is that I should type more carefully!
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:
<a href=blah.blah>{GETTEXT: _EDITLINK}</a>
Lawrence Akka
-------------------------------------------------
FROM: nada.kth.se
DATE: 11/27/2001 10:09:21
SUBJECT: RE: [Phpwiki-talk] About languages
--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by my.nada.kth.se id
TAA14304
On Tue, Nov 27, 2001 at 09:29:45AM -0800, Jeff Dairiki wrote:
> Yes, all the non-english templates are currently broken in PhpWiki 1.3.
I've just made a small update (po, pgrsc, and templates) to the
Swedish translation of 1.2 (attached, I hope it's ok?) and I'll fix it
for the 1.3 line as well, but not tonight.
==========NOTICE==========
Internet e-mail is not necessarily secure or reliable. Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...
|
|
From: Jeff D. <da...@da...> - 2001-11-28 16:41:05
|
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?
|
|
From: Reini U. <ru...@x-...> - 2001-11-29 05:36:29
|
Jeff Dairiki schrieb:
> <a href="http://..."><?php echo gettext("Some text."); ?></a>
> Perhaps we could support a more compact syntax...
<a href="http://..."><?=_("Some text.")_?></a>
should work. almost perl'ish :)
you have to enable the ASP tags syntax in php.ini (which is default)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Reini U. <ru...@x-...> - 2001-11-29 05:42:49
|
Reini Urban schrieb:
> <a href="http://..."><?=_("Some text.")_?></a>
^
oops:
<a href="http://..."><?=_("Some text.")?></a>
|
|
From: Carsten K. <car...@ma...> - 2001-12-01 22:34:18
|
Today while I was adding a few more German translations to the
template/Edit.html I realized a small problem in using the _("text")
function to translate localized text, has this already been discussed?
Different languages have different word ordering. When a key word needs to
be added to the end of a sentence in english, it might need to be inserted
into the middle of the sentence in another language.
For example:
English:
$_("Author will be logged as") <i>${USERID}</i>.
German:
$_("Der Autor wird als") <i>${USERID}</i> aufgenommen.
Is there an existing way around this? Without a code-based solution Wiki
may be stuck with individual localized templates.
Carsten
On Thursday, November 29, 2001, at 12:42 am, Reini Urban wrote:
> Reini Urban schrieb:
>> <a href="http://..."><?=_("Some text.")_?></a>
> ^
>
> oops:
> <a href="http://..."><?=_("Some text.")?></a>
>
|
|
From: Reini U. <ru...@x-...> - 2001-12-02 01:44:04
|
Carsten Klapp schrieb:
> Today while I was adding a few more German translations to the
> template/Edit.html I realized a small problem in using the _("text")
> function to translate localized text, has this already been discussed?
>
> Different languages have different word ordering. When a key word needs to
> be added to the end of a sentence in english, it might need to be inserted
> into the middle of the sentence in another language.
>
> For example:
>
> English:
> $_("Author will be logged as") <i>${USERID}</i>.
>
> German:
> $_("Der Autor wird als") <i>${USERID}</i> aufgenommen.
>
> Is there an existing way around this? Without a code-based solution Wiki
> may be stuck with individual localized templates.
The standard answer is sprintf.
sprintf(_("Der Autor wird als %s aufgenommen"), "<i>$USERID</i>")
But this imposes problems to at least my hord of inexperienced translators.
(they don't know about %s or %d, they don't know what value will be inserted,
which variable, and how many % vars need to be inserted)
So I use a limited set of variables which get expanded at run-time from
the definitions strings.
something like:
register_gettext_expansion('USERID');
echo x_('Der Autor wird als $USERID aufgenommen');
writing this from scratch... (totally untested. I use a completely
different translation scheme on my current project. translators do it online).
I register only uppercase vars for this.
function register_gettext_expansion ($var) {
if (!is_array($GLOBALS['GETTEXT_VARS']))
$GLOBALS['GETTEXT_VARS'] = array();
$GLOBALS['GETTEXT_VARS'][] = $var;
}
function x_($msg) {
$msg = gettext($msg);
// this could be improved to expand on all vars in the msg,
// not on all existing vars...
if (!(($i = strpos($msg, '$')) === false) and
(substr($msg,$i-1,1) != '\\')) {
foreach ($GLOBALS['GETTEXT_VARS'] as $s) {
if (!empty($GLOBALS[$s]))
$msg = str_replace('$' . $s, $GLOBALS[$s], $msg);
}
}
return $msg;
}
The problem is that $ must be quoted and that I did't check for that in
my old version. Luckily I don't have us money in my strings :)
Another problem is that the gettext extraction tools only recognize
_("") and not _(''). so we must use
echo x_("Der Autor wird als \$USERID aufgenommen");
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Carsten K. <car...@ma...> - 2001-12-07 22:53:52
|
I found a code snippet demonstrating how to automatically determine the
default language selected in a user's browser. May be useful for offering
a default language choice in the user preferences.
Carsten
<?php
// language codes are comma delimited
$lang = strtok ( $HTTP_ACCEPT_LANGUAGE, "," );
while ( $lang ) {
//if there is "en" in it
if ( strstr ( $lang, "en" ) ) {
header ( "Location: http://localhost/english/" );
exit;
}
if ( strstr ( $lang, "es" ) ) {
header ( "Location: http://localhost/castellano/" );
exit;
}
if ( strstr ( $lang, "nl" ) ) {
header ( "Location: http://localhost/nederlands/" );
exit;
}
if ( strstr ( $lang, "de" ) ) {
header ( "Location: http://localhost/deutsch/" );
exit;
}
$lang = strtok( "," );
} //next token and end of while
// default relocation in case nothing got detected
header ("Location: http://localhost/english/");
exit;
?>
On Wednesday, November 28, 2001, at 11:40 am, Jeff Dairiki wrote:
> 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.
>
|
|
From: Reini U. <ru...@x-...> - 2001-12-09 16:44:54
|
Carsten Klapp schrieb:
> <?php
> // language codes are comma delimited
> $lang = strtok ( $HTTP_ACCEPT_LANGUAGE, "," );
> while ( $lang ) {
> //if there is "en" in it
> if ( strstr ( $lang, "en" ) ) {
> header ( "Location: http://localhost/english/" );
> exit;
...
better is to check the first 2 chars only.
if ( substr($lang, 0,2) == "en" )
otherwise we might get a match on the secondary specification. (de_at)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Lawrence A. <la...@20...> - 2001-11-28 17:19:48
|
At 16:40 28/11/2001, Jeff Dairiki wrote:
> > 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...
>
What about {_WhateverText}.
Template.php could then pick use a regexp to pick up {_(.*)} (or whatever
- not sure if that one works). and yank in the necessary translation.
WOuld only cause a problem if someone wanted to use {_ in their template.
>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?
I agree.
Lawrence
==========NOTICE==========
Internet e-mail is not necessarily secure or reliable. Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...
|
|
From: Jeff D. <da...@da...> - 2001-11-28 17:47:50
|
On Wed, 28 Nov 2001 17:19:37 +0000
"Lawrence Akka" <la...@20...> wrote:
> What about {_WhateverText}.
The one other thing to consider is that it would be nice to use a syntax
which can be grokked by xgettext (which is designed for picking gettext()
calls out of C code). Some options which work:
gettext("string")
$gettext("string")
_("Text string")
$_("string")
(The parentheses around a "-quoted string are the key.)
These are all somewhat ugly, but acceptable, I think. Of the above
choices, I like $_("this one").
(The other option would be to write our own replacement or pre-filter for
xgettext. :-/ )
> >The _() abbreviation is standard usage --- the gettext tools support it
by
> >default.
Correction: GNU xgettext doesn't support _() by default, you must include
the '-k_' command line argument. The _() is fairly standard usage
however, and stock PHP does define '_' as an alias for 'gettext'.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X