Ambiguous string clashes when localizing in wp-admin/export.php l

[RanYanivHartstein]

When localizing to certain languages, the string "All" in the authors list in wp-admin/export.php (which means "All authors") clashes with other usages of "All".

In English, "All" can be used for "Everyone" as well as "Everything" - for e.g., in WordPress, it can be used for "All categories" as well as "All authors".

In other languages, such as Hebrew, the two are separate, and using the same term for localizing causes a clash.

I enclosed a patch that changes the string to "All authors" in wp-admin/export.php to avoid the clash.

[RanYanivHartstein]

Patch to avoid clashin string in wp-admin/export.php

[westi]

Currently we have 'All' in three places in trunk:

./wp-admin/export.php:<option value="all" selected="selected"><?php _e('All'); ?></option>
./wp-admin/edit.php:            <?php wp_dropdown_categories('show_option_all='.__('All').'&hide_empty=1&hierarchical=1&show_count=1&selected='.$cat);?>
./wp-admin/link-manager.php:$select_cat .= '<option value="all"'  . (($cat_id == 'all') ? " selected='selected'" : '') . '>' . __('All') . "</option>\n";

And we need to something consistent for all of them.

Maybe we should continue using All but give them context?

[RanYanivHartstein]

I can say that for Hebrew, these are all identical and are translated the same.

However, I'm guessing other languages will have other problems, and it would be best to make sure strings are not repeated in different contexts.

Ideally, we should add comments or specific context in the string itself.

For e.g. in link-manager.php:

__('All categories')

or

_c('All|categories')

[westi]

I think in the contexts that they are currently used with the surronding text or label detailing that it is all categories or all ... I would prefer if we switched to the the strings with context.

[RanYanivHartstein]

Replying to westi:

I think in the contexts that they are currently used with the surronding text or label detailing that it is all categories or all ... I would prefer if we switched to the the strings with context.

This is more of a UI issue. Either way (literally specifying the contexts/using hidden comments) should be good enough as far as l10n is concerned.

[RanYanivHartstein]

Any news on this for 2.5?

[ryan]

(In [6836]) Change strong to avoid gettext ambiguity. Props RanYanivHartstein. fixes #5515

[ryan]

Went with your patch since the more specific text seems better. We can address the larger issue of context in a different ticket.