Twenty Eleven localization problems

[pavelevap]

After translating and testing new Twenty Eleven theme, I will add some patches to this ticket...

1) Missing textdomain from contextual help (Theme Options). Patch attached.

Note that in this patch I did not add textdomain to 2 strings, because they are also in main WP localization file. I am not sure if it is better to directly use these original WP strings or add special theme textdomain? Adding textdomain would duplicate same strings to more files and translators would have to translate these strings on both places...

Missing textdomain patch

I think it would be better to always use the textdomain.

Thank you for changing title of this ticket. Sorry, my mistake.

But standardization of some repeating strings could be better for translators - creating standard strings. This problem can be seen better for Post Formats. They are predefined by WordPress and also translated. Can not be changed by developers. But in Twenty Eleven translators have to translate them once again because there is twentyeleven textdomain?

See for example content-aside.php, line 17:

<?php _e( 'Aside', 'twentyeleven' ); ?>

So one translator can translate "Aside" in WordPress and another translator with different meaning in Twenty Eleven. But it should be the same...

If we can, can we try to avoid talk about duplicate strings here? Most of it has been rehashed in #14972 already, comments can be added there (even without re-opening the ticket).

For now, if we can cover any final translation issues with Twenty Eleven for release, that'd be a better use of everyones time :)

I kind of agree that get_post_format_strings() should probably be used in Twenty Eleven.

Updated patch

Updated patch applies twentyeleven textdomain for all strings from contextual help...

2) Another small problem is duplicated string "Pages". For some Post Formats templates there is wp_link_pages() function called with string

Pages:

but for others it is string

<span>Pages:</span>

I did not find differences, so it could be united? I can create patch, but I am not sure which way (with span or without)? BTW, what is the meaning of function wp_link_page() for Link, Image, etc?

3) File content-aside.php, line 54: Function comments_popup_link ignores specific plural forms. There is only one plural form

<b>%</b> Replies

but many languages have more plural forms. BTW why HTML b and not strong?

The same problem is in file inc/widgets.php, lines 94 and 110. Once again function comments_popup_link makes problem for translators.

See this ticket (with High priority) for reference: ​http://core.trac.wordpress.org/ticket/13651

In [18235]:

Add missing textdomain to twentyeleven contextual help. Props pavelevap. see #17744

get_post_format_strings()

Alright, It does make sense to use that, however, only if the public facing language is the same as what's used in the backend. Some people might have a Localised backend, and choose to have the theme in English, in that case, it'd use the localised values when it shouldn't.

Leaving it for the theme (like it currently is done) results in the best outcome for readers of a website, not only is everything consistantly in one language, but the grammar/tone/dialect used in each translation is the same. (But vice-versa, If different people translate the front and backend, the resulting translation may differ, which would be more confusing for the Writer of the site)

Example of implementing this at present however: echo get_post_format_string('aside');

comments_popup_link ignores specific plural forms. There is only one plural form

Unfortunately, A proper fix for this never got into WordPress 3.2 (#13651) so you're stuck with it how it is in Twenty Eleven, Just treat it the same as you did in Twenty Ten (By using an overly generic word?)

BTW why HTML b and not strong?

Thats among the things listed on #17748 at present.

wp_link_pages()

That's definately used inconsistently. The proper output for the theme is for the text to be wrapped in <span> tags, as it styles it to alter the margin between the word and the numbers. However, we can make it easier on translators here by moving the <span> out of the translated text.

In [18312]:

Consistently wrap the "Pages:" text in <span> tags, Combine the 2 identical translations for the Pages text (one with, and one without, span tags). See #17744

All seem fixed.

Using theme textdomain translations for Post Formats was not resolved, I guess...

Using theme textdomain translations for Post Formats was not resolved, I guess...

I think it's best for us to do as we're currently doing, and have the formats double translated. The front end translation may not be the same as the backend,