2008/1/22, Lionel Elie Mamane <[EMAIL PROTECTED]>:
> reopen 461617
> retitle 461617 wordpress: support for all (upstream-supported) languages
> tags 461617 =l10n
> thanks
>
> >> One step: Internationalise (convert to gettext) all remaining
> >> strings in the code. (Such as "could not connect to database", the
> >> initial blog setup process, ...)
>
> > Unfortunately at that stage gettext can't be loaded, so these error
> > messages, and some other files cannot be translated using gettext.
>
> OK, I'm sorry if I come with somewhat stupid questions, or ideas you
> already considered and rejected, but I'd like to understand. Thanks
> for bearing with me (else skip the next quote of you).
>
> While I completely understand e.g. why the error message for
> non-existent wp-config.php cannot use gettext (language to use not
> known yet), I don't understand why, for example, gettext cannot be
> loaded before making the database connection. After all, the path to
> gettext is not in the database, is it? Maybe there is some other
> reason that things are loaded in this order. Maybe I would understand
> why if I tried to actually make the change :)
>
> wp-admin/setup-config.php: It runs independent from wordpress, OK. But
> why can't it use gettext? If the only problem is that wp-config.php
> doesn't exist yet to know what language to use, it could start with a
> language selection screen, couldn't it? In the context of Debian, we
> have a Debian-specific script that creates the MySQL user and database
> and creates the wp-config.php file, so setup-config.php isn't used at
> all.
We need plugins loaded in order to translate strings. Plugins can
modify current locale or translate strings in other way, not gettext.
However, in order to plugins to be loaded we need the database
running.
I agree about setup-config.php though. We can see what mo files are
there and if there is only one -- use it, if there are more (which
will be a quite rare case) we can let users select.
>
> What we should do is have the wp-config.php file include a language
> setting. Added to my TODO list.
>
> > You should decide whether you want to provide full translations
> > including all error messages, readme and translated first post,
> > first comment and user roles.
>
> Well, we would like to have as much translated as is feasible without
> duplicating the whole code. We don't want to duplicate the whole code
> because then it is a bit nightmarish for security updates: instead of
> one copy of the code to correct it, suddenly we have 20+ copies to
> handle. The same holds for non-security updates, actually :)
>
> What I would be OK with is a scheme where we have one copy of the code
> (with English strings or placeholders like @WP_STRING_ERR_NO_CONFIG@),
> and string translations are provided in some kind of flat-text file
> and then we automatically produce the localised versions by statically
> replacing the strings/placeholders in the code. If we use
> placeholders, something along the lines of
>
> for l in ${wp_supported_languages}
> for f in ${wp_static_translation_files}; do
> cp $f $f.tmp
> for str in ${wp_string_list}; do
> lstr=$(lookup_translation $l $str)
> sed "s/$str/$lstr/" < $f.tmp > $f.tmp2
> cp $f.tmp2 $f.tmp
> done
> cp $f.tmp wordpress-$l/$f
> done
> done
>
> would do. There are probably still some kinks to be ironed out, but
> would that be imaginable for Wordpress 2.5? I can prepare a patch for
> this infrastructure, if you want.
We have been thinking for some time, how can we deal with that problem
and solutions like yours have been suggested many times I don't want
to make WordPress depend on a build stage. If we incorporate this
scheme we will have to replace the placeholders before using the
software. Also, after we have once replaced them, we are losing the
actual placeholders and upgrades can be a nightmare.
> Open problem: plugin descriptions. I suppose the wordpress PHP code
> could call gettext on the string after retrieving it from the comments
> in wp-content/plugins/PLUGIN.php ? Something like
>
> <td class='desc'><p>{__($plugin_data['Description'])}$author</p></td>
>
> instead of
>
> <td class='desc'><p>{$plugin_data['Description']}$author</p></td>
>
>
> I looked only at the French translation up to now. Another thing that
> bothers me a bit is code differences between the English and French
> versions of Wordpress. Some are French-specific code, but don't break
> other languages. An example is (in tinymce):
>
> if ($mce_locale = 'fr_FR') {
> $mce_locale = 'fr';
> }
>
> Could this kind of code be folded back into wordpress itself?
They should name their tinymce translations fr_fr.js and this patch
won't be needed.
>
> Still in tinymce, there is the
>
> spellchecker_languages : ...,
>
> line. Could this one be generated dynamically, depending on which
> languages are supported in the current installation?
Yeah, we have to allow dynamic spellchecker languages addition.
>
>
> > If the mo files are enough for you, you can take them from the svn
> > repository [1].
>
> So there _is_ a central place to get the translations from. Great!
> I'll write a script to automatically scour that repository, extract
> all tagged-with-current-version translations and put them in the
> Debian package, then.
>
> > I can ask the translators to tag their work after each version, so
> > that you can automatically grab the mo files.
>
> Yes, that would be great, thanks.
>
> >> Another step: Gettextise strings in themes (or at least the default
> >> theme).
>
> > You can find a i18n-ed version of the default theme in our
> > wordpress-i18n svn repository [2].
>
> > Translators are encouraged to put their default theme translation in
> > wordpress-i18n/<locale_dir>/<branch>/messages/kubrick/<locale>.mo.
>
> (Note that we would prefer getting the .po files and compiling them to
> .mo ourselves; this fits better under Debian's philosophy of taking
> source code from upstream and compiling it ourselves. Even if in this
> case the compilation is greatly reversible. I don't expect this would
> create any trouble on your side.)
The po files are also in the repo, so feel free to use them.
>
> Oh, goody. What would you recommend doing for now? Relying on
> wordpress-i18n/<locale_dir>/tags/<version>/messages/kubrick/<locale>.po
> for the default theme, or importing the
> wordpress-i18n/<locale_dir>/tags/<version>/theme/default/
> ? In other words: can we expect a reasonable number of languages to
> make a kubrick/<locale>.po available? I see that for example, French
> doesn't have one yet.
Just until several months we didn't have the i18n-ed version of the
default theme and most of the themes have it translated by hand (and
kept in the theme/ directory in their repos). I can't say when/if all
of them will switch to gettext.
>
>
> While you are at it, a comment about hhtp://bugs.debian.org/461584 ?
It sounds very much like http://trac.wordpress.org/ticket/5517
Happy hacking,
Nikolay.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
