Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No real plural support in i18n solution #2005

Open
stefan-scholl opened this issue Aug 30, 2016 · 1 comment
Open

No real plural support in i18n solution #2005

stefan-scholl opened this issue Aug 30, 2016 · 1 comment

Comments

@stefan-scholl
Copy link

It should be mentioned somewhere (or fixed) that plural support is very limited. It may even be unusable for some languages.

It only supports singular and plural. No 0 (zero) or different plural translations.

Some languages have the plural for 0 items, some have the singular. And some languages have different plurals for different numbers of items.

See http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html#Plural-forms

@ryancramerdesign
Copy link
Owner

We try to utilize solutions that will cover most cases to ensure it's simple enough that people will actually use it. Have you found a spot where it's causing confusion? Let me know where and I can update. In cases where there might be potential for confusion over zero conditions, I prefer to treat them independently, i.e.

$n = count($items);
if($n) {
  echo sprintf(_n('Found %d item', 'Found %d items', $n), $n); 
} else {
  echo __('Sorry, no items were found.'); 
}

PW doesn't know anything about the rules of different languages, and that's intended. Developers can add as many languages as they want, but PW doesn't know that one is English and another is Chinese and what other rules that might entail. We leave language-specific rules to the developer implementing the language.

What I may be able to do is amend the _n() function to support 4 arguments, and treat the first as a 0 condition when it detects there are 4 arguments. That's still not going to cover every possible need here, so beyond that, my preference is less complexity/higher-usage, and let the edge cases be handled by the developer and situation where it is required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants