Oops while rendering +translate page for empty POFile

[Jeroen T. Vermeulen]

We're getting these errors on some +translate pages:

LocationError: (<zope.browserpage.metaconfigure.SimpleViewClass from /srv/edge.launchpad.net/edge/launchpad-rev-10224/lib/lp/translations/browser/../templates/translationmessage-translate.pt object at 0x2aaab50d8e10>, 'autofocus_html_id')

Example URL: https://translations.edge.launchpad.net/ubuntu/karmic/+source/indicator-messages/+pots/indicator-messages/ab/1/+translate

OOPS-1486EC432, OOPS-1486EC433, OOPS-1486EB328

[Jeroen T. Vermeulen (jtv)]

I believe the problem is that POFileTranslateView._initializeTranslationMessageViews is being called with an empty batch. That means that _buildTranslationMessageViews produces an empty translationmessage_views, which autofocus_html_id then tries to index.

Note that the example is in Abkhazian (ab), which is pretty rare and so I'd guess that the translation is probably empty. Substituting e.g. Arabic (ar) does work.

[Jeroen T. Vermeulen (jtv)]

I can reproduce the problem for languages where Launchpad lacks the plural information. For those languages we show no translatable messages and direct the user to submit plural information instead. That would explain the empty batches.

[Jeroen T. Vermeulen (jtv)]

The part I can't explain as yet is why any of this should be a problem. The indexing error should be caught, and an empty id returned. Is an empty return value a problem somehow? Or is something completely different going wrong?

[Jeroen T. Vermeulen (jtv)]

Silly me! The special-case code that directs users to submit plural info bypasses initialization altogether.

[Jeroen T. Vermeulen (jtv)]

Gah. POFileTranslateView.initialize _also_ bypasses the initialization under some circumstances. POFileTranslateView.translationmessage_views should be at least created much more aggressively.

[Jeroen T. Vermeulen (jtv)]

Adi reports that this is fallout from problems with his fix for bug 359180. He has a better fix waiting, but it didn't make it in before PQM closure.

[Adi Roiban (adiroiban)]

The problem is in browser/translationmessage.py

    def _messages_html_id(self):
        order = []
        message = self.translationmessage_view
        if (message.form_is_writeable):
            for dictionary in message.translation_dictionaries:
                order.append(
                    dictionary['html_id_translation'] + '_new')
        return order

-------------
Maybe this will help:

    def _messages_html_id(self):
        order = []
        message = self.translationmessage_view
        # If we don't know about plural forms, or there are some other
        # reason that prevent translations, translationmessage_view is
        # not created
       if ((message is not None) and (message.form_is_writeable)):
            for dictionary in message.translation_dictionaries:
                order.append(
                    dictionary['html_id_translation'] + '_new')
        return order

[Jeroen T. Vermeulen (jtv)]

We discussed this on IRC and concluded that the best thing to do is to back out the original fix for bug 359180: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/10113

The proper fix can then go in next cycle.

[Jeroen T. Vermeulen (jtv)]

Adi's branch and another were merged into production-devel (through db-stable, I suppose) together. To revert, I'm using:

    bzr merge . -r 7675.2450.59..7675.2450.58

This produced one strange conflict on the inclusion of event-key.js in base-layout-macros.pt. One version of the text included that, the other didn't. I think I'm erring on the safe side by keeping it in.