Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#17744 closed defect (bug) (fixed)

Twenty Eleven localization problems

Reported by: pavelevap's profile pavelevap Owned by:
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.2
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

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...

Attachments (2)

missing_textdomain.patch (3.0 KB) - added by pavelevap 14 years ago.
Missing textdomain patch
missing_textdomain_2.patch (3.1 KB) - added by pavelevap 14 years ago.
Updated patch

Download all attachments as: .zip

Change History (18)

@pavelevap
14 years ago

Missing textdomain patch

#1 @nacin
14 years ago

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

#2 @dd32
14 years ago

  • Milestone changed from Awaiting Review to 3.2
  • Summary changed from Twenty Ten localization problems to Twenty Eleven localization problems

#3 @pavelevap
14 years ago

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...

#4 @dd32
14 years ago

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 :)

#5 @nacin
14 years ago

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

@pavelevap
14 years ago

Updated patch

#6 @pavelevap
14 years ago

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

#7 @pavelevap
14 years ago

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?

#8 @pavelevap
14 years ago

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

#9 @ryan
14 years ago

In [18235]:

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

#10 @nacin
14 years ago

  • Component changed from I18N to Bundled Theme

#11 @dd32
14 years ago

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.

#12 @dd32
14 years ago

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

#13 @azaozz
14 years ago

  • Resolution set to fixed
  • Status changed from new to closed

All seem fixed.

#14 @pavelevap
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#15 @dd32
14 years ago

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,

#16 @nacin
14 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.