2008/2/16, Lionel Elie Mamane <[EMAIL PROTECTED]>: > On Sat, Feb 16, 2008 at 08:33:59AM +0100, Lionel Elie Mamane wrote: > > On Thu, Jan 31, 2008 at 04:18:38PM +0200, Nikolay Bachiyski wrote: > > >> However, I like the idea of specially-formatted comments -- something > like: > > >> wp_die(/*WP_I18N_NOWPCONF*/"There doesn't seem to be a > >> <code>wp-config.php</code> file..."/*/WP_I18N_NOWPCONF*/"); > > >> Thus we can put these strings into the mo file and replace them on the > >> localized package build stage. > > > I'm starting a shell script "proof of concept" implementation after > > breakfast. > > Herewith attached is: > > - a (partial) patch for wordpress 2.3.3 > - a tarball with my static-l10n code, and example .po files for > English and French, with some. > > for a first draft of what it would look like. Please let me know what > you think; in particular, if I finish it and polish it up, is it good > for commit in Wordpress (I'll send a patch against trunk in that case, > obviously). Here is how it is used: > > tar xfz i18n-tools-0.0.1.tar.gz /some/place > /some/place/compile-static-i18n > /some/place/translate-static /path/to/wordpress/tree LANGUAGE_CODE > > This will translate the static strings between /*WP_I18N_START_FOO*/ > and /*WP_I18N_END_FOO*/ in files where they occur. The list of values > for FOO and the list of files is static in the translate-static > script. > > It requires sed, a POSIX-compliant /bin/sh and GNU gettext installed. > > The suggested way for a programmer to change the English string is to > change it in en.po and run translate-static. And then, warn all > translators. Or we can drop en.po and developers can have the fun of > chasing every occurrence of the string and change it the same way > everywhere; they'd still have to warn translators. See also below. > > Where shall we place the contents of the said tarball? Directly as a > subdirectory "l10n-tools" of wordpress? In a separate SVN repository > (maybe where I would commit directly), e.g. in the wordpress-i18n > repository, under tools? > > Bugs and problems: > > - The translator sees the FOO part of the placeholder (e.g. NOWPCONF) > as msgid instead of the English version of the string; he has to > look up in the code or in en.po what the English version of that > string is.
This one should be avoided, or we will have to automatically strip the <WP_...> and </WP...> parts from translation. > > As a consequence, if a programmer changes the English version of > the string in the code, there is no automatic way for the > translators to be notified (the string does not become "fuzzy" in > gettext terms). This is not a big problem. > > Fixing that is a bit problematic; to look up the English string > instead of the placeholder, I'd have to interpret PHP strings, > something I'm not very eager to code up in shell... We will make it in php, because it has a decent tokenizer. Also, we will need some custom code for extracting strings, elsewhere. > > - The implementation does not support multi-line strings and it is a > bit delicate to add that support. Mainly include/wp-db.php contains > multi-line strings. Would it be OK to change them to single-line > strings, with \n escapes for newlines? If we write it in php it will be less of a problem :-) Would you mind if we move the discussion to our wp-hackers list [0]? I want the devs to check it out also. It would be nice if you drop a mail there with the idea, and after that we can write a ticket, put the code and polish it. [0] http://lists.automattic.com/mailman/listinfo/wp-hackers Happy hacking, Nikolay. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]