[RFC|Merged] Plural forms

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Plural forms

Post by nickvergessen » Tue Sep 13, 2011 11:33 am

The language array for AGO currently looks like this:

Code: Select all

		'AGO'		=> array(
			0		=> 'less than a minute ago',
			1		=> '%d minute ago',
			2		=> '%d minutes ago',
			60		=> '1 hour ago',
		),
So when you have a relative date/time setting ( |D d.m.Y| H:i ) it displayes "less than a minute ago" and such messages.
The problem is that the "60" case will not be reached anymore, because the plural rule will calculate the case we shall use for a value 60.
Things like this may also be done by MODs.

E.g. a user could have edited this case:

Code: Select all

	'NUM_POSTS_IN_QUEUE'		=> array(
		0			=> 'No posts in queue',		// 0
		1			=> '1 post in queue',		// 1
		2			=> '%d posts in queue',		// 2+
	),
to

Code: Select all

	'NUM_POSTS_IN_QUEUE'		=> array(
		0			=> 'No posts in queue',		// 0
		1			=> '1 post in queue',		// 1
		2			=> '%d posts in queue',		// 2-25
		25			=> 'Moderators go do your job or you get fired!',		// 25+
	),
The question here is, whether we just say "this is an abuse case and it is not going to be supported from now on" (maybe also throw an debug message when such a language array is detected)
or whether we try to find a way to implement lang() so it supports both ways.
Member of the Development-TeamNo Support via PM

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Plural forms

Post by nickvergessen » Tue Sep 13, 2011 1:37 pm

Fixed the AGO string, by removing the '1 hour ago' string:
https://github.com/nickvergessen/phpbb3 ... 02d64a1c56
commit message wrote:This message was only viewed for 1 second anyway,
as floor($delta / 60) is only 60 for 3600 to 3660,
but the code was limited to $delta <= 3600
Member of the Development-TeamNo Support via PM

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Plural forms

Post by nickvergessen » Tue Sep 13, 2011 4:12 pm

Mael can you ask the translators, whether things like in the MCP stats
Total members: {NUM}
are okay or whether they need to be different aswell?

E.g. in english you say "Total users 1" aswell and not "Total user 1"

Or Most users ever online was <strong>%1$s</strong> on %2$s
Member of the Development-TeamNo Support via PM

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Plural forms

Post by nickvergessen » Wed Sep 14, 2011 9:01 pm

Mael could you also ask, whether:
75.00% of all posts
0.12 posts per day
need different translations aswell? or what happens when it is a float number, not an int?

Same for
'Page <strong>1</strong> of <strong>2</strong>'
Member of the Development-TeamNo Support via PM

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: Plural forms

Post by Oleg » Thu Sep 15, 2011 6:35 am

I read the diff, I'm really liking the removal of all of the sprintfs in client code, it looks like it is actually easier/less work to use language strings now than before.

I have a comment about the 0 case. I think this case should be optional. In English we can use "many" for 0. Sometimes we may want to have a special translation for 0 things, other times that translation is identical to the one for many case.

Thus I would suggest checking if the version for 0 exists, and if it does not use whichever version works for "many".

In case the appropriate version differs between languages, this might need to be another parameter (like plural rule to use) that a language pack has to specify. If there must be a 0 case for each translation the fallback for 0 may be defined as 0.

With this fallback added a bunch of 0 cases that are the same as many cases could be deleted from the default language pack.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: Plural forms

Post by Oleg » Thu Sep 15, 2011 6:44 am

nickvergessen wrote:
Oleg wrote:I came across Symfony Translation component and it appears to also do things the Right Way(TM).

https://github.com/symfony/symfony/tree ... ranslation
Well seems like a huge list of language iso-s ;)

I'd go the way of https://developer.mozilla.org/en/Locali ... ural_Rules
So we basically implement the rules (mostly the same as in symfony) but use a int key which rule to take.
Language package authors than simply specify the rule they want to use.

This has the advantage that we do not need to list all packages in the source or need to update it when a new lang package got submitted.
I like this choice (on a technical level).

I also see than symfony has some hacks in place to fix whatever issues with languages, we don't need to have that in our core code with the proposed patch.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: Plural forms

Post by Oleg » Thu Sep 15, 2011 6:56 am

(18:05:39) nickvergessen: https://gist.github.com/1215299 bantu looks like 3.1 is the better option :( this is everything from outside adm/
(18:06:16) bantu: nickvergessen: just make it 3.1
(18:06:17) nickvergessen: or what do you think?
(18:06:40) bantu: such things really should not happen in a stable branch
(18:06:49) bantu: we should rather release more often
I would tend to agree, the feature is a nice one to have but the volume of changes is getting quite large for a stable branch.

Plus this would be a great marketing point for 3.1 :)

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Plural forms

Post by nickvergessen » Thu Sep 15, 2011 10:11 am

I already rebased it on develop and changed the fix version of the ticket, so it will be 3.1

Regarding the 0, it already falls back from 0 to the biggest number, but yes, not to the zero-case the language would have to use.
I also added a lot of 0 and 1 cases now, for testing and seeing, I also thing it would be much easier for the translators.
Sometimes the only case that is used for English language is the many-case.
We could than just use a normal string instead of an array, but translators of "difficult" language packs would than need to see that by theirselves and replace it with an array. I don't know, what the best solution for this issue is.
Member of the Development-TeamNo Support via PM

User avatar
ledzef
Registered User
Posts: 4
Joined: Fri Nov 11, 2011 1:27 am

Re: Plural forms

Post by ledzef » Fri Nov 11, 2011 4:35 am

I've been searching for this. Nice work. Thanks for all the suggestion. It helps me continuing my task. :D

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC|Merged] Plural forms

Post by Oleg » Sat Dec 03, 2011 8:51 pm

Moved to RFC forum, and merged.

Post Reply