Re: [xliff-users] Plural handling in XLIFF 2.0?

Thanks Oytun! I had missed the old Plural Entries feature page, but that does look like a starting point.

I agree that this is also a more general problem (gender, etc). We were discussing this on an Okapi call a couple weeks back and it was mentioned that the ICU format (http://userguide.icu-project.org/formatparse/messages) supports gender and plurals, but noted that this becomes a complex matrix quite quickly.

The json-lang example is interesting.

On Tue, Mar 29, 2016 at 11:05 AM, Oytun Tez <oytuntez@gmail.com> wrote:

To me this is a problem bigger than plurals. This is a contextual issue which we really need to cover very soon.

On an experimental localization exchange format I worked on last year, I tried to solve this with a concept that I then called "contexts". If you go to http://json-lang.org/ and search for "Contexts" title, there are some examples. We need more flexibility in string definitions, especially considering our target groups in applications we develop have been expanding rapidly and this brings a huge variety of strings, with minimal contextual changes (singular, plural, female, male, kind, casual etc). XLIFF has a similar feature, but the other way around: http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html#context-group

In specific to plurality, XLIFF 2.0 has a proposed Plural Entities specification: https://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries. But it looks like there wasn't much activity around this.

---
Oytun Tez

M O T A W O R D - The World's Fastest Human Translation Platform.
J S O N - L A N G - JSON specification for localization file exchange.
I AM A FACT - Entrepreneurification!

On Tue, Mar 29, 2016 at 1:49 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:
Hi all,

The other day I was talking to somebody who asked me why there wasn't a standard way to handle plural forms in existing interchange formats. I didn't have a good answer, so I thought I'd raise the question here.

I think the rise of mobile formats is driving this issue to the front. It has always been present in software string localization, but in my experience it was typically confined to a single format within a given organization (PO or Qt TS, for example). However, app developers now have separate formats for iOS and Android (at least), each of which may be doing very similar plural handling.

I don't have specific functionality in mind, but it like this problem space might be a good fit for an XLIFF 2.0 module. Is this an area the TC has previously investigated?

ct

xliff-users message