[wp-hackers] Re: no-code-duplication i18n for WordPress
Lionel Elie Mamane
lionel at mamane.lu
Thu Mar 6 13:32:28 GMT 2008
On Tue, Mar 04, 2008 at 08:14:05PM +0100, Francesc Hervada-Sala wrote:
> Am Dienstag, 4. März 2008 09:04:12 schrieb Lionel Elie Mamane:
>> I'm Lionel Elie Mamane, I recently got involved in the Debian
>> packaging of WordPress, and I'd like to propose you an enhancement in
>> your full-i18n procedures, so that all languages are guaranteed to
>> use the same code, only strings differ.
> I find your proposal is perfect. The localization would be a lot
> easier and faster and lesser errorprone. I am not sure whether the
> WordPress-developers must agree with this -- In my opinion this is a
> pure i18n issue, isn't it?
Well, it would be much preferable to have their assent and
cooperation; after all we need them to apply the patch adding the
special comments, and to put the special comments around any new
hard-coded string in future. I also found it preferable to allow
everyone to comment, make suggestions, etc. (Maybe they don't like the
special comments I've chosen and would prefer something shorter, or on
the contrary, longer and more self-explanatory. Things like that.)
Up to now, I've been getting only positive comments, both on
wp-polyglots and wp-hackers, so it looks like it is going to happen
sooner or later.
> I volunteer for testing this building of localized versions, if I
> can be helpful anyhow.
Thanks. Do you know how to create and apply patches? If not, tell me,
I'll prepare ready-to-download tarballs. If yes, download
http://people.debian.org/~lmamane/wordpress/no-code-dup-i18n-poc-v2.patch,
and apply it to a svn trunk checkout, do the work described below and
send me the resulting patch.
The biggest work remaining is going through the sources and tag all
hard-coded strings (_not_ those already gettext-internationalised,
that is inside a call to a __() or _e() or ... !). By "tagging" a
string, I mean add the exact sequence of characters "/* WP_I18N_START
*/" (without the double quotes) before it and the exact sequence "/*
WP_I18N_END */" (without the double quotes) after it. You can put one
start/end pair around code that contains several strings, which are
all to be translated. See also the examples in my original message and
in my patch.
If a hard-coded string contains variable references, that is things
such as "$foo" or "{$foo}", it should be replaced by a sprintf
structure. For example,
wp_die("Could not connect to DB host $host, I'm all confused now", 'Fatal error');
should become
/* WP_I18N_START */ wp_die(sprintf("Could not connect to DB host %s, I'm all confused now", $host), 'Fatal error'); /* WP_I18N_END */
We should probably also tag things like upgrade download URLs, default
blogroll URLs in the default theme, etc, as some translation teams
have their own for that.
Could you do that? If nobody else does, I'll try to do it in the
week-end, but I won't be able to do it before.
Once the strings are tagged, MAKE A COPY OF THE SOURCES WITH THE TAGS
(but the strings still in the original English), and send me the
patch.
Then, run the "i18n-tools/generate-pot" script; it will output a .pot
file to stdout. Use it to produce a .po file, and from it a .mo file
as you usually do. Then, run the i18n-tools/translate-static script,
which will translate the tagged string. Check that they are all
translated and that the sources differ in no other way. If one of
these properties does not hold, it is a bug, please tell me about it.
The "translate-static" step is NOT (trivially) reversible, so make a
backup of the sources before you apply it!
If you have any question, let met know.
--
Lionel
More information about the wp-hackers
mailing list