The localizers have been hitting this bug since Friday but I wasn't able to reproduce. First I thought it was related to a particular nightly, but today I also see in Google Chrome. This the URL that gives me an empty page (only Verbatim's header and footer is displayed): https://localize.mozilla.org/pl/badges/LC_MESSAGES/messages.po/translate/?unit=850420 I also heard that the following one didn't work either, but I still can't repro: https://localize.mozilla.org/rm/twitterparty/LC_MESSAGES/messages.po/translate/?unit=849893 The errors in the console are: [18:43:40.632] o is undefined @ https://localize.mozilla.org/html/js/jquery/jquery.scrollTo.min.js:11 [18:43:40.981] $.pootle is undefined @ https://localize.mozilla.org/html/js/mt/google-translate.js:7 This is blocking some languages and we have a lot projects going on right now for the launch of Firefox. It would be great if this is fixed quickly.
I tried several methods to reproduce it basing on feedback from @lzyczkowski. - tried Opera, Chrome, Firefox 3.6, Minefield - tried Linux and MacOS (Teo reproduced it on WinXP, I don't have it) - tried with a temp account with different privileges to the project - tried with some of the extensions that Teo uses (including AdBlock) I was unable to reproduce it at all :(
I can show it to you on my machine on Tuesday.
BTW it looks like this only happens when the user is logged in.
Some detail description about this bug: This happens only if I'm logged in. To string #25 all is OK. After click string #26 I see only Verbatim's header and footer. See attached screeshot and try this link after logged in. https://localize.mozilla.org/pl/twitterparty/LC_MESSAGES/messages.po/translate/?unit=849893
@Stas: so you are able to reproduce it after all?
Yes. See below. (In reply to comment #0) > This the URL that gives me an empty page (only Verbatim's header and footer is > displayed): > > https://localize.mozilla.org/pl/badges/LC_MESSAGES/messages.po/translate/?unit=850420
I get the same bug on this URL: https://localize.mozilla.org/it/glow/LC_MESSAGES/messages.po/translate/?unit=865176 (last string, 21st, of global map project)
Oh, andm since Stas asked for it... My OS is Debian testing, the browser is Firefox 3.6.15 (x64 self-compiled based on Mozilla sources)
Gandalf and I were able to debug this and find the reason. The culprit is the 'Number of Rows' setting in your account's settings tab: https://localize.mozilla.org/accounts/edit/ If this number is too big, Verbatim doesn't show last strings for projects with very small number of strings. Examples: My setting was 20 and I couldn't see strings from 11th on in the Badges projects. I'm guessing that Gion-Andri's and Leszek's setting was 50 -- they weren't able to see the 26th strings of the Twitter Party project. CC'ing Friedel and Alaa.
Just to complete the following examples, I'll add the total number of strings below. > My setting was 20 and I couldn't see strings from 11th on in the Badges > projects. Total strings: 12 (<20) > I'm guessing that Gion-Andri's and Leszek's setting was 50 -- they weren't able > to see the 26th strings of the Twitter Party project. Total strings: 41 (<50)
That's a fine job you guys did there figuring this out. Woot!
Created attachment 518317 [details] [diff] [review] Patch to fix the issue Just been able to reproduce the bug with the given details, thanks Staś. This trivial patch should fix it, at least works fine locally.
Hi Julen, Thanks for the patch. I tested it and I'm afraid that it introduces a different problem. 1. I set my 'Number of Rows' to 50 to keep things consistent with others reporters of this bug. 2. The patch indeed fixes the problem of small projects, like Badges (12 strings) and Twitter Party (41 strings). Note that all of those are less than my new setting (50). 3. A new problem appears for bigger projects. I tested with Firefox Cup (60 string). This should be paginated into two pages: page 1 with 49 strings (as per my setting) and page 2 with 11 remaining strings. 4. However, when I try to access any of the strings no. 50-60, Verbatim shows my strings 1-11 instead. It tells me that I'm on page 2 and shows me some 11 strings, but they are not the right strings. Can you see this too?
(In reply to comment #15) > > Can you see this too? Yes I see. Then checking if it's the first page should be enough I think, otherwise it'll always pick the first units in the queryset.
Created attachment 519250 [details] [diff] [review] Patch to fix the issue This should hopefully do the right thing.
What is the status of this bug? I don't have access to Verbatim so cannot verify
Has anybody been able to test the patch (attachment 519250 [details] [diff] [review])? It would be great to have it confirmed and in the next release.
Peterbe, do you have a working dev instance of verbatim handy and can help out the Pootle guys with comment 19?
I tested this with Peter today and I wasn't able to reproduce. Upon investigation, it turned out that the lines that Julen's patch would remove are now gone in the code -- the bug must have been fixed by one of the regular Pootle updates on the Verbatim server. Thanks everyone! Resolving fixed.