Timeout errors in +translate

I think tha the correct link is:
https://launchpad.net/distros/ubuntu/dapper/+source/vlc/+translations

And it gives the following:
"No translatable templates available

Dapper vlc does not have any strings to be translated through Rosetta. If you think this is incorrect, please send an email to the Rosetta mailing list or file a bug in our bug tracking system so we can look into the problem. Thanks. "
BR,

We removed vlc from dapper because it's from Universe and dapper is not able to handle translations from Rosetta for Universe, that's why that link is not valid anymore.

Anyway, the bug is valid and the OOPS code is everything we need to fix this problem.

Recent OOPS-215B106

Just to add more: OOPS-212B34, OOPS-212C22, OOPS-212C26, OOPS-212D37, OOPS-212C257, OOPS-212D262, OOPS-213B269, OOPS-213C244

Potato back in my court.

Just one more.. OOPS-438BA1

Another one, and this one seems to fail always, a reload is not enough: OOPS-465C1255

a new uoooopsss OOPS-470C63 unforutnately potatos getting heavier over hear...

Changing importance to High as per kiko's comment on today's meeting. It still is the top time out oops and it'd be nice to have it fixed for 1.1

Handing off; I will give Jeroen my suggestions on how to refactor this.

First phase of fix in revision 4382. More coming.

Second phase of fix in revision 4398. Now to see whether it works in practice.

Phase 4 is in revision 4654. An optimization involving a schema change this time.

Phase 5 is in revision 4712. Reduces the number of queries issued on this page. For now, still contains an assertion (bug 132660) that keeps the number close to its old level, but once validated, that assertion can be removed.

Phase 6 is on the way, with a further reduction in queries and data sets.

Phase-6 optimization landed in RF 4770.

Phase 7 is in RF 4816; phase 8 is in RF 4873.

I keep getting a timeout when trying to access the Catalan translation of Wengophone:

https://translations.edge.launchpad.net/wengophone/2.2/+pots/qtwengophone/ca/+translate

The error ID is OOPS-670EA54 (altough I've also seen OOPS-666EA107), and I've also reported it at launchpad-users as suggested [1]. I have tried to access the translation page several times in the last week, but the timeout always occurs.

Along with the fact that since last week PO files cannot be exported, this makes it impossible to translate that project at the moment, so I'll probably have to resort to bypass Launchpad Translations completely and contact the Wengophone developers to send me the file directly.

I believe this might be related to this bug, or at least the symptoms are. If not, please let me know and I'll file a new one instead.

Thanks.

[1] https://lists.ubuntu.com/archives/launchpad-users/2007-October/002586.html

Two things should help: trying to load a page before the moment you actually need it, and simply trying again. For instance, when I tried this Catalan Wengophone page it timed out the first time, but when I reloaded the page it worked.

Jeroen,

thanks for your reply, but I had also tried the "reload trick" without success before I posted my comments. Of the many times I reloaded the page in the numerous occasions I have tried to access it, Launchpad only managed to load it in two of them.

But this was of no use as as soon as I entered some translations and pressed "Save", the page timed out again.

So I have given up trying to use the web interface. Finally the exported po file landed in my inbox, so I translated it directly, and as soon as I could load the +translate page without timeout on the second occasion, I simply imported the po file.

I too face the problem with the below URL:
https://translations.edge.launchpad.net/ubuntu/gutsy/+source/kdelibs/+pots/kdelibs/te/+translate

The error I see is:
Sorry, something just went wrong in Launchpad. We've recorded what happened, and we'll fix it as soon as possible. Apologies for the inconvenience.
Trying again in a couple of minutes might work. If it doesn't, and this is blocking your work, let us know on the launchpad-users mailing list (requires subscription). Include the error ID OOPS-675EA32 in your message.

I've upload new pot template to QBzr project (https://launchpad.net/qbzr/). Now I can't work with translations at all: all the time I got timeout error (last one: OOPS-681F571), download translations is also broken, i.e. it still (2 days after request) don't e-mail me link for download. How can I workaround this?

The translation downloads are being used much more heavily now than before and this leads to much longer waiting times. We're working on improving performance; until then, it may make more sense to work in a PO file editor and upload the resulting files.

Jeroen,

the problem is that the option to export the PO file for the preferred language is only available from the +translate page. So if the +translate page times out, there is no chance to download the PO file.

There is the option of downloading the whole translation (i.e. with all languages), which is available on the initial page of the package, but last time I did that it took about a week until the file was in my inbox.

What I have found to work is to bypass the +translate page and simply enter the link to the export page, i.e.:

https://translations.edge.launchpad.net/ubuntu/gutsy/+source/gnome-system-monitor/+pots/gnome-system-monitor/ca/+export

this particular link allows me to export the Catalan translation of the gnome-system-monitor as a workaround for the fact that the +translate page keeps timing out -and hence the po file cannot be exported through the usual means.

In any case, even when working locally, there is currently also the problem of importing, which has been taking an average of 10 days for the files I have recently imported.

Hadn't realized it also made the download link inaccessible. Thanks for bringing that up.

We're just polishing off our big schema refactoring and it should make a big difference. There may be teething problems, but we're concentrating our efforts there.

Import queue performance has been addressed separately. We've seen a massive speed increase there, and there's more coming with this release. But all this has done a lot to distract us from the manual vetting process for new uploads, so we're behind on approving those.

We really hope it's finally fixed with RF 5199.

Maybe we don't kill all timeouts, but they should be reduced a lot and should be easy to kill any remaining one.

Today new version of Launchpad was rolled out. As I see in page footer it's build 5220 now.
Unfortunately I have the same timeouts problems as before. Nothing changed.

Actually, much changed, but you are right that there is still an oddly reliable timeout happening. I'm not sure if this is just because the query optimizer needs to learn to do the new queries, if we are missing an index, or if the query needs to be rewritten. We're looking into it.

So, what is the preferred way for we users to help solving this? Should we still report any timeouts to launchpad-users, or keep commenting them on this bug report?

For now, I can observe the following reproduceable timeouts:

https://translations.launchpad.net/ubuntu/gutsy/+source/gnome-panel/+pots/gnome-panel-2.0/ca/+translate
(error ID OOPS-694B499)

https://translations.launchpad.net/ubuntu/gutsy/+source/gnome-app-install/+pots/gnome-app-install/ca/+translate?start=10
(error ID OOPS-694D484)

https://translations.launchpad.net/wengophone/2.2/+pots/qtwengophone/ca/+translate
(error ID OOPS-694B503)

On all cases reloading the page on the browser did not help, and the page will never load.

For now, the best course of action is waiting for Monday. We'll be
working on sorting it out then.

Those three URLs for reproducible timeouts work for me now, and are in fact quite fast. It's possible that their data has been moved into caches since the rollout.

Meanwhile we've identified another suspect that has more to do with system configuration than with programming. I'm not sure when this is going to be addressed but we are making it a priority and it shouldn't take long.

Jeroen T. Vermeulen wrote:
> Those three URLs for reproducible timeouts work for me now, and are in
> fact quite fast. It's possible that their data has been moved into
> caches since the rollout.
>
> Meanwhile we've identified another suspect that has more to do with
> system configuration than with programming. I'm not sure when this is
> going to be addressed but we are making it a priority and it shouldn't
> take long.
>

Not cache - I was able to create a targeted index for the failing query.
This should last until we can address the config issue.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Stuart Bishop пишет:
> Jeroen T. Vermeulen wrote:
>> Those three URLs for reproducible timeouts work for me now, and are in
>> fact quite fast. It's possible that their data has been moved into
>> caches since the rollout.
>>
>> Meanwhile we've identified another suspect that has more to do with
>> system configuration than with programming. I'm not sure when this is
>> going to be addressed but we are making it a priority and it shouldn't
>> take long.
>>
>
> Not cache - I was able to create a targeted index for the failing query.
> This should last until we can address the config issue.

Is there another bug report about config issue, so I can subscribe to
stay informed? Because translations of projects where I involved
are still inaccessible.

Please, for any other new issue you have, file a new bug

Alexander, please file new bugs with specific URLs. This bug is closed.

URL: https://translations.launchpad.net/ubuntu/eoan/+source/gtk+3.0/+pots/gtk-3.0/af/+translate?field.alternative_language=af&field.alternative_language-empty-marker=1&memo=0&show=untranslated
Timeout error
(Error ID: OOPS-f4be95aa035e30559b5eb136e9ab472d)
Sorry, something just went wrong in Launchpad.

We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.

Trying again in a couple of minutes might work.
THANK ALL OF YOU FOR ALL OF YOUR HARD WORK WITHIN LAUNCHPAD.. BERNARD