Not return s behind non-English

[PeterTeng]

WHY

Language such as Japanese, Chinese... on pluralize usage will be like

pluralize('テスト', 5, true)
//=> "5 テストs"

pluralize('蘋果', 2, true)
//=> "2 蘋果s"

Found this issue when using https://github.com/fnando/i18n-js

[coveralls]

Coverage remained the same at 100.0% when pulling e545b62 on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[coveralls]

Coverage remained the same at 100.0% when pulling e545b62 on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[coveralls]

Coverage remained the same at 100.0% when pulling e545b62 on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[blakeembrey]

Can you give me more information on how you're using this? The library definitely wouldn't work with any non-English words anyway, so trying to add support for it seems like overkill. If you're doing i18n you should really provide both singular and plural cases instead of trying to let a library like this guess it too (it can fail, whereas you probably won't).

[PeterTeng]

Japanese, Chinese, Korean... countries that use Chinese character lacks plural marking for most nouns. So just found that if prevent non-English pruralize and provide cases in other language have plural marking.
This is not supporting pluralize in other languages but to prevent non-English.

However I got your point! Maybe it's better to handle cases out of library!

provide both singular and plural cases instead of trying to let a library like this guess it

You can close this if you think there is no further discussion😄

[blakeembrey]

I was just curious of the use-case. I do understand the need to avoid appending s in character-based languages, but I'd like to suggest that this module never be used outside of an English setting. The link you gave me didn't give a lot of context on why the module was being used in a setting that non-ASCII characters could be passed to it. I think I can merge it with a minor change anyway, but I'd still love to understand where it's being used.

If you can change the + in the RegExp to $, I think it will be acceptable. In the current form, there's no need to match more than one character (if I understand what you intended to do), but also we only care about the ending (e.g. 四 chicken should still become 四 chickens).

[PeterTeng]

but also we only care about the ending (e.g. 四 chicken should still become 四 chickens). 👍

Here is an example

const FollowerCount = () => {
  return (
    <div>
      { pluralize(I18n.t("some.scoped.translation.follower"), 4, true) }
    </div>
  );
};

When locale is English, will render

<div>
  4 followers
</div>

When locale is Japanese, will render

<div>
  4 フォロワー
</div>

The truth is that this will be only a big help when localizing languages that lacks with plural marking...

c.f.
Rails' active_support pluralize is considering locale information, but default as en
https://github.com/rails/rails/blob/4db7540caf1ff716611173966d1fb0e9ec64c6f2/activesupport/lib/active_support/inflector/methods.rb#L29-L31

[coveralls]

Coverage remained the same at 100.0% when pulling a34683d on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[coveralls]

Coverage remained the same at 100.0% when pulling a34683d on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 72bdcb7 on PeterTeng:peter/handle-non-english into 9b71c46 on blakeembrey:master.

[blakeembrey]

Thanks. The sample makes sense. I believe that having the actual i18n translations is going to be better than using this library, as you'd have more control - especially over positioning, but I will definitely merge this PR. Thanks!

As for the i18n library, maybe it could have a mini-template library built in so you could do I18n.t("some.scoped.translation.follower", { followers: 4 }) and the templates look something like: { en: '{followers} follower{? followers !== 1 }s{?}', jp: '{followers} フォロワー' }.

^ Not real code or template language. Do you have an example of what you're doing today? It's definitely interesting to me since i18n is something I would love to get more experience with, but my typical job would never require it.

[blakeembrey]

Right to left inside a left to right document is really confusing, and the GitHub UI does not make it easier here 👍

[PeterTeng]

Thank you for your quick response to this pull request!

While the project getting bigger the translation file will get bigger too. The considerable error on i18n is missing key(scope) of translation. It's true that provide actual i18n translation is going to be better. However, languages with plural marking behind (or front or somewhere), most of them have the rule to pluralize. Some of them might have packages for it. Or adding rules in utility.

Just a quick search, I found this https://github.com/swestrich/pluralize-fr

I found this package will be really helpful on service language based on languages lack plural marking, and try to localize to English. Which can simply handle the cases.

This will keep simple on translation with numbers. The project such as localizing on Analytics Dashboard will extremely helpful

Maybe this is the way to handle

const I18n = window.I18n;
import pluralizeEN from 'thisPackage';
import pkuralizeFR from 'pluralize-fr';

export function pluralize(singular, count, showCount = false) {
  const word = String(singular);
  if (I18n.locale === 'en') {
    return pluralizeEN(singular, count, showCount);
  }
  if (I18n.locale === 'fr') {
    return pkuralizeFR(singular, count, showCount);
  }
        .
        .
        .
  return `${count}${word}`;
}