Posted by archetwist on March 7, 2006 at 3:47pm
10 followers
| Project: | Drupal core |
| Version: | 6.x-dev |
| Component: | locale.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (cannot reproduce) |
Issue Summary
1) Plural forms are displayed incorrectly, e.g. the string '2 reads' should be translated to '2 odsłony' and '5 reads' to '5 odsłon' but both are displayed using the word 'odsłony'.
2) Another user told me that he did not have a problem with plural forms but had to disable Polish translation in order to access admin/taxonomy page. After reenabling it everything was fine.
As far as I remember in the former versions there were no problems of that kind. I think there is something wrong with translations' handling in beta5.
Comments
#1
1) Do you use the correct plural formula for Polish?
2) I really need more info.
#2
1) Yes, I do. As I said there was no such a problem in beta4 and older versions.
2) I am afraid I cannot tell you anything more about that.
I think these two are just two variants of the same problem.
#3
1) I don't think that there were any changes to format_plural. MAybe you found a place in the code where it isn't used. Can you tell me on which page the string occurred?
2) then it is difficult to help. CAn you repdoduce the problem yourself?
#4
1) The string occurs on almost every page :) because reads counter is displayed in the links section of every node. It is impossible that I found a place where this format_plural is not used because I do remember this string had been properly displayed and it is displayed correctly in other users' Drupal installations (though I did not manage to fix this bug at my site - reinstallation of the Polish translation did not help).
2) I will ask the user I mentioned earlier to post some details about this.
To make it more clear, the reason I do not think that the problem #1 is caused by an error in the translation itself is because older Drupals displayed plural forms of the string correctly and the reason I assumed these two problems are somewhat connected is because both of them had shown up in beta5 and both concern translation.
#5
1) $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads');
This is from the statistics_links function. I don't think thus has changed between beta 4 and beta 5.
2) ok, waiting for feedback.
#6
1) Yes, this line looks the same in beta4.
#7
well i am the one that had problems with admin/taxonomy... after upgrade (from version 167 as the update script has recognized) there was strange behaviour in this area of the site. There was "Page not found" alert at the top of the page (in polish), then help text (starting with "The taxonomy module allows you to...") and then footer of the page - no categories table... clicking link "add vocabulary" returned same thing...
After i switched to english language admin/taxonomy was allright, and it is ok now, when i switched back to polish files...
In my log there are some entries of this episode :) that is all i can remember, site runs properly now so i cant recreate this issue...
#8
I have just checked and the same thing is happening with %count attachments. I really do not have any idea why plural forms are displayed incorrectly at my site and, even worse, how to fix this.
As to problem #2 unfortunately that Drupaller cannot tell us anything more and I do not feel like installing another Drupal just to confirm this - #1 bothers my head.
#9
can you post a sql dump of your locales_meta table?
#10
Sure.
CREATE TABLE `locales_meta` (
`locale` varchar(12) NOT NULL default '',
`name` varchar(64) NOT NULL default '',
`enabled` int(2) NOT NULL default '0',
`isdefault` int(2) NOT NULL default '0',
`plurals` int(1) NOT NULL default '0',
`formula` varchar(128) NOT NULL default '',
PRIMARY KEY (`locale`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `locales_meta` (`locale`, `name`, `enabled`, `isdefault`, `plurals`, `formula`) VALUES ('pl', 'Polish', 1, 1, 0, '');
INSERT INTO `locales_meta` (`locale`, `name`, `enabled`, `isdefault`, `plurals`, `formula`) VALUES ('en', 'English', 1, 0, 0, '');
#11
Just as I thought: no plural formula is defined. Can you compare this to an old sql dump of the same table? Did you recently import any PO files?
#12
From an old backup copy:
INSERT INTO `locales_meta` VALUES ('en','English',1,0,0,''),('pl','Polish',1,1,3,'(($n==1)?(0):((((($n%10)>=2)&&(($n%10)<=4))&&((($n%100)<10)||(($n%100)>=20)))?(1):2))');I have just copied the formula and set plural's value to 3 and plural forms are back. Hooray! Thank you killes for your help.
I imported some PO files but that was after I had noticed this bug.
#13
I'd like to find out when the plural formula got lost. I think it could have happened that you imported a PO file that did not have a proper plural formula.
#14
Either plural formula got lost during the upgrade or I have serious problems with my memory ;) because I remember that before I did the upgrade plural forms had been displayed correctly and I had not imported any translations.
#15
There weren't any updates which changed the locales_meta table.
#16
fixed.
#17
#18
The problem with plural forms is still persistent. As you can see other users have similar problems. It's quite unlikely that 3 different translations (Polish, Ukrainian, Russian) have incorrect formulas.
#19
hi,
I fixed this issue.
Attached patch for locale.inc.
When you import .po file, it's header information with plural formula is losted .
And locales_meta table is updated with blank.
#20
Hooray!
#21
archetwist, did you test the patch?
#22
Yes, I did. It seems to be OK now.
#23
ok, applied to 4.7 cvs. Here is a patch for HEAD, rolled from the docroot.
#24
Great team work. Committed to CVS HEAD.
#25
#26
Still NOT fixed!
After each .po importing I have to
update locales_meta set formula='my_language_formula' where locale='my_language_code'cause field `formula` - becomes empty
#27
Is this really fixed or not?!
@theque: please provide some steps and examples to really validate the correct functionality of plural forms!
#28
I doubt there were plural formula changes from 4.7 onwards to 6.x, and it seems this bug is not present in 6.x. At least my test site works fine. If this bug still stands, can someone provide a test case and an exact version where the bug can be reproduced?
#29
The bug appears to be fixed. Please re-open if needed.