Support plural forms

[jobi]

A feature request, we would love it twine supported plural forms. Something like:

[delete_things]
    en:one = Delete this object?
    en:other = Delete these objects?

Android has support for plural forms in its string resources:

    <plurals
        name="plural_name">
        <item
            quantity=["zero" | "one" | "two" | "few" | "many" | "other"]
            >text_string</item>
    </plurals>

iOS could use Smartling

gettext also has support for plural forms

[scottdweber]

A very good idea! We have actually talked about this briefly, but have not taken it any further than casual discussion.

[yincrash]

The way I currently do plurals in twine is having a separate key for each plural, such as cool_things_one cool_things_other, then do

    <plurals
        name="cool_things">
        <item quantity="one">@string/cool_things_one</item>
        <item quantity="other">@string/cool_things_other</item>
    </plurals>

in a separate xml file in values/ that isn't managed by twine.

[jobi]

@yincrash that's a pretty good solution, but that means we need to maintain the list of keys in 2 places

[scelis]

iOS and Mac actually support plurals natively as of 10.9 and iOS 7. You can read about this in the 10.9 Foundation Release Notes.

That said, plurals are tricky. One of the goals for Twine has been to maintain a simple feature set that all of the string file formats support. By fully supporting plural forms for Android, Mac, and iOS, we have to be careful that we don't prevent those strings from being written out to other formats like jQuery, gettext, etc.

I think the trick to implementing this feature properly is to use some sort of convention such that all strings can be written out to all formats. Maybe the twine syntax is modified as @jobi suggested. Plurals could be written out to formats that support it and those that don't will get multiple strings with well-defined suffixes like "delete_things__one", "delete_things__many", etc.

[pichirichi]

This is a great idea @scelis , I like this approach.
This is even a challenge when sending strings for translation since most services don't support the plural format.

[scelis]

The more I think about this feature, the more I think that the benefits do not outweigh the additional complexity.

[wujessica]

We had this problem consolidating Android and iOS translations for our app and we ended up implementing it in a project fork (with some convention ideas from here!). We'd be happy to send a PR if you think that would be useful.

[scelis]

@wujessica Thanks for this! I am sure others may find it useful. It might be hard to merge into the main repo until we figure out how it functions with the other (non-iOS and Android) formatters.

[mvarshavsky]

@scelis - any way I can convince you to revisit your cost/benefit analysis above :) Any project will sooner or later encounter the need to pluralize. Having to maintain a separate per-platform file as @yincrash is doing it brings the problem twine is solving right back (granted, on a smaller scale). It seems like there must be a way to unlock this functionality for plural-aware formatters, while keeping it neutral for the rest (e.g., by convention only picking the first of key:qty occurrences). Also, if using up :blah just for this purpose it too greedy, a more generic scheme can be applied.

[scelis]

@mvarshavsky Is there really great cost to not using plurals in your string files? We use plurals in our apps all the time and it requires just a few lines of code given our twine string file:

if numItems == 1 {
    label.string = localizedString("NumItemsSingular", numItems)
} else {
    label.string = localizedString("NumItemsPlural", numItems)
}

So yeah, I don't think that the amount of complexity this would add to twine would be worth it just to turn the above chunk of code into:

label.string = localizedString("NumItemsWithPlurals", numItems)

[mvarshavsky]

A lot of time it's three: no items / 1 item / n items - but that's besides the point; in my eyes it's just ugly superfluous code that detracts from readability. My belief is that placeholders/interpolation (which twine has) and ability to pluralize is something that all decent-sized projects eventually need and therefore all platforms will eventually evolve to support. I get you're trying to keep complexity out - but that choice pushes it to all consumers of your library :) Anyway, I'm not here to argue, it's your decision, just chiming in with another "+1" on the feature request. We have @wujessica's fork to fall back on. Appreciate all the work you've put into this!

[scottdweber]

Another consideration is that, while the following code works just fine for English and some other languages, there are many languages where such logic may not be appropriate (e.g. Korean, Chinese, Russian, etc.). These cases are where the platform's in-built plurals system helps you, and requires a more robust set of translations.

if numItems == 1 {
  // singular
} else {
  // plural
}