[2.2] [Translation] added support for translations depending on gender and number of variables #4884

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
4 participants
@sroddy

sroddy commented Jul 12, 2012

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
References: #4797
Fixes the following tickets: -
License of the code: MIT

This improvement adds to the translator component the possibility to pass variables specifying the gender and the number. This enables the translators to handle all the specificities of their own language. With an easy to understand but strict syntax, I've managed not to break the BC, while adding a very small footprint in the trans method (due to a single validation regexp which is anyways improvable).

This the syntax ref of a translated message:

%variable% [gender][plural_position]: String

Where
%variable% is any kind of string (all characters except spaces and |),
[gender] is one of the following: m n f (male, female, neuter)
[plural_position] is an integer that follows the same convetions of the pluralization rules that you can find in Symfony\Component\Translation\PluralizationRules
String is any kind of string (except the | sign)

You can specify (and it's highly reccomended) a generic translation as the first position (without using any specific syntax).
This will be returned in case no other translation matches the given parameters.

Some examples follow:
%user% wrote on %friend%'s wall for his/her birthday | %friend% f: %user% wrote on %friend%'s wall for her birthday | %friend% m: %user% wrote on %friend%'s wall for his birthday

You are a very good boy! | %user% m1: You are very good boys! | %user% f0: You are a very good girl! | %user% 1f: You are very good girls!

I'd like to hear some feedbacks about this implementation so I can adjust what you think is wrong and then write the documentation.

@stof

View changes

src/Symfony/Component/Translation/MessageSelector.php
+ *
+ * @throws InvalidArgumentException
+ *
+ * @api

This comment has been minimized.

@stof

stof Jul 12, 2012

Member

you should not tag is as @api as it is not part of the stable api (it is not even part of the codebase yet)

@stof

stof Jul 12, 2012

Member

you should not tag is as @api as it is not part of the stable api (it is not even part of the codebase yet)

This comment has been minimized.

@sroddy

sroddy Jul 12, 2012

sorry, it was a wrong copy-paste :) fixed

@sroddy

sroddy Jul 12, 2012

sorry, it was a wrong copy-paste :) fixed

@sroddy

This comment has been minimized.

Show comment
Hide comment
@sroddy

sroddy Sep 13, 2012

@fabpot what do you think about this feature? I'm already using it heavely in my current installation and I personally think it's a far better approach compared to the transchoice method because that method has to be invoked by the programmer and not by the translator, as this one.

sroddy commented Sep 13, 2012

@fabpot what do you think about this feature? I'm already using it heavely in my current installation and I personally think it's a far better approach compared to the transchoice method because that method has to be invoked by the programmer and not by the translator, as this one.

@guilhermeblanco

This comment has been minimized.

Show comment
Hide comment
@guilhermeblanco

guilhermeblanco Sep 27, 2012

Contributor

After some discussion with @sroddy, we throught it would be better if we strictly follow the pluralization rules defined by unicode.org: http://unicode.org/repos/cldr-tmp/trunk/charts/supplemental/language_plural_rules.html
That way, it would not be more 0, 1, etc, but actually, zero, one, two, few, many and other.
Considering that we also have genders as: male and female and neutral for example, we could update the translation keys to a standardized solution, like:

variable[gender][pluralization]

That way, we could do something like:

$translation = implode("|", array(
"aboutMyMatch[male][one]: About him",
"aboutMyMatch[male][other]: About them",
"aboutMyMatch[female][one]: About her",
));

We also consider defining only one or none of the elements, like only defining gender, but not pluralization, or defining only the pluralization (which would consider the gender as neutral). For most of the pluralization rules, the plural goes into a male translation. But it would be up to the developer to define how the genders should be named. For example:

thing[cat][one]: Foo

As an ability to make it flexible, developers would be able to define anything except the plural rules names and the | sign. Finally, they give a TranslatableInterface, which would require the methods getGender and getNumber to be implemented. These two methods would be used internally of Translation component to retrieve the correct elements and find the correct/best match translation key option.

Contributor

guilhermeblanco commented Sep 27, 2012

After some discussion with @sroddy, we throught it would be better if we strictly follow the pluralization rules defined by unicode.org: http://unicode.org/repos/cldr-tmp/trunk/charts/supplemental/language_plural_rules.html
That way, it would not be more 0, 1, etc, but actually, zero, one, two, few, many and other.
Considering that we also have genders as: male and female and neutral for example, we could update the translation keys to a standardized solution, like:

variable[gender][pluralization]

That way, we could do something like:

$translation = implode("|", array(
"aboutMyMatch[male][one]: About him",
"aboutMyMatch[male][other]: About them",
"aboutMyMatch[female][one]: About her",
));

We also consider defining only one or none of the elements, like only defining gender, but not pluralization, or defining only the pluralization (which would consider the gender as neutral). For most of the pluralization rules, the plural goes into a male translation. But it would be up to the developer to define how the genders should be named. For example:

thing[cat][one]: Foo

As an ability to make it flexible, developers would be able to define anything except the plural rules names and the | sign. Finally, they give a TranslatableInterface, which would require the methods getGender and getNumber to be implemented. These two methods would be used internally of Translation component to retrieve the correct elements and find the correct/best match translation key option.

@sroddy

This comment has been minimized.

Show comment
Hide comment
@sroddy

sroddy Oct 1, 2012

@fabpot @stof we would love to hear some feedbacks before starting to implement these changes. If we are totally out of scope, it's better not to start either. The idea is to change this PR according to the unicode plural rules and the a-bit more-verbose-but-much-clearer 'var[gender][pluralization]:' syntax. I'd love to hear a feedback from @schmittjoh too, because his really useful JMSTranslationBundle will be even more useful to help translators with this kind of syntax.

sroddy commented Oct 1, 2012

@fabpot @stof we would love to hear some feedbacks before starting to implement these changes. If we are totally out of scope, it's better not to start either. The idea is to change this PR according to the unicode plural rules and the a-bit more-verbose-but-much-clearer 'var[gender][pluralization]:' syntax. I'd love to hear a feedback from @schmittjoh too, because his really useful JMSTranslationBundle will be even more useful to help translators with this kind of syntax.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Mar 26, 2014

Member

Closing in favor of #6009

Member

fabpot commented Mar 26, 2014

Closing in favor of #6009

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