[wp-hackers] Using constants for text domain

[Justas Butkus]

2013.11.27 21:28, Otto rašė:
> ... and that fails on two entirely different levels. ;)
>
> Rather than explain in great detail, I'll refer you to three of my posts:
>
> 1.
> http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/
>
> 2. http://ottopress.com/2012/more-internationalization-fun/
>
> 3. http://ottopress.com/2013/language-packs-101-prepwork/
>
> The first one will explain why using $string and PLUGINPREFIX_TEXT_DOMAIN
> are incorrect.
>
> The second one will make you aware of a few more functions you might not
> know about.
>
> The third will tell you how to refactor a bit so that you can properly
> support the upcoming Language Pack system in WordPress.
>
> If you have questions, ask. :)
Hello.

Thank you, Otto, for taking time. I will only respond to this message, 
as I see your other message repeats, in some portions, what you have 
posted previously on your blog.

I believe it's quite obvious that the last entry from your blog makes 
the greatest impression.
We have been employing some internal solution based on GlotPress, 
despite we are not providing translations of our own, except for the 
one, that users contribute, and that takes time to review, adjust, etc. 
for inclusion in some release.

Even if language packs are not yet available and built on WordPress - we 
are very likely to change our build process.
Though as plugin-specific class was introduced for several reasons, it's 
likely to stay in development environment, but as long as we employ 
tools, which operate on AST level, it might be rather trivial to replace 
the calls to our methods to their counterpart methods from WordPress 
stack, modifying and/or amending arguments as needed.

While two first articles are interesting, but I believe anyone working 
in a multinational team is likely to learn fast and early, that grammar 
is not alike across languages. Actually on your second article I am 
missing information about plural forms, which allow virtually infinite 
translation table entries for `_n` family calls, bottom line being that 
WordPress handles it the way it should.

Another thing which keeps me interested for quite long - how well 
translators, who have nil programming experience, handle variable 
swapping - given initial entry is '%d', how likely a translator is to 
change it to '%3$d'. That either tells me, that we have to always put 
full specifier ('I will have %1$d tacos and %2$d buritos'), or turn to 
using non-positional system, like 'I will have {number_tacos} tacos and 
{number_buritos} buritos', which would be later replaced with 
appropriate values, but that might also cause the confusion, when 
translator might decide to change '{number_tacos}' to '{@!#!@_!@#@!}'. 
But this is clearly not the point of this discussion.

One last thing remains on my mind, which is likely to generate some 
heat, which I would like to avoid, but I can't ignore the issue. The 
performance case. Assume we know, that we are going to call `date_i18n` 
some thousand times during a page load. With just three distinct forms 
which all are static and used within a single loop that has no external 
dependency, thus voiding possibility of translation string modification 
in between. Just for the sake of discussion - assume, that we have a way 
to ensure, that no dynamic elements are to be introduced in the final 
string. In that sense it seems kind of logical, to use intermediate 
representation, which generates the resulting string, which might then 
be passed to some simplified date (timestamp) formatter. As I said - 
just for the sake of discussion it would be good if we could assume we 
have really analysed the data, intermediate forms, resulting forms as 
well as resolved date adjustment issues. Also I would prefer to not get 
into the discussion about incremental loading and the likes here. What's 
your view on this issue? As using some cache might shave a full second, 
resulting in generously acceptable, instead of terribly slow. This is 
accidentally last - it's important to us, and we have employed several 
different solutions.

Once again - thank you for your kind responses. And for pointing at the 
planned introduction of language packs - which seems like a really 
awesome addition to WordPress.



-- 
Regards,
Justas Butkus