Translation message link points to wrong message number

Bug #403629 reported by David Planella
60
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Critical
j.c.sackett

Bug Description

If I go to:

https://translations.launchpad.net/ubuntu/jaunty/+source/gdebi/+pots/gdebi/ca/+translate?show=untranslated&start=0

and then I click on the magnifying glass icon to view more info about this message or to e.g. get a link for this message, I am taken to the following URL:

https://translations.launchpad.net/ubuntu/jaunty/+source/gdebi/+pots/gdebi/ca/0/+translate

which takes me to a non-existing page in Launchpad.

The number in the link should be 78 (for this particular message) instead of 0. I guess this has to do with the filter being used, but the link is still wrong.

On a separate issue, strangely enough, this message does not show the location of the string in the source code.

While I cannot find an exact match in the recent oopses, I think this OOPS-34f95b6e8613730d7df67780f8d0ffb7 is an example. While working with a batch, there is a link to a zero message. This link in the oops is not in the batch when I see it, which makes me think the batch or the data is mutating.

Related branches

Revision history for this message
Basic (basicxp) wrote :

I could confirm this too, tested on Firefox 3.5.1 on Windows Vista. This is definately a bug in Rosetta.

Issue #2: This is not a bug. The location of the string is usually written in po/pot file like this:
# Comment
#: Location of string
msgid "String"
msgstr "Translated string"
The file with that string is just missing the "#: ... " row.

Revision history for this message
Данило Шеган (danilo) wrote :

This happens when we are showing used suggestions from obsolete messages. The message is probably obsolete but with a translation in Karmic.

Changed in rosetta:
importance: Undecided → High
status: New → Triaged
tags: added: message-sharing
Revision history for this message
Robert Collins (lifeless) wrote :

The sample url in the bug report works now; is the data fixed, or the bug fixed?

Revision history for this message
Robert Collins (lifeless) wrote :

(If the bug is still present, this will generate OOPSes and count as critical - so upgrading accordingly; but it may be closable).

Changed in launchpad:
importance: High → Critical
description: updated
tags: added: 404
William Grant (wgrant)
summary: - Message link points to wrong message number
+ Translation message link points to wrong message number
Curtis Hovey (sinzui)
description: updated
Revision history for this message
Curtis Hovey (sinzui) wrote :

Once again oopses are pruned even though they are mentioned in a bug. This is relevant information from the most recent oops:OOPS-2f4094bb443cc9b345119c97977098a7

URL: https://translations.launchpad.net/granite/trunk/+pots/granite/uk/0
Referrer: https://translations.launchpad.net/granite/trunk/+pots/granite/uk/2/+translate?field.alternative_language=uk&field.alternative_language-empty-marker=1
User: Anonymous User

Traceback

  NotFound: Object: <POFile at 0x193768d0>, name: u'0'

    Traceback (most recent call last):
  Module zope.publisher.publish, line 131, in publish
    obj = request.traverse(obj)
  Module zope.publisher.browser, line 542, in traverse
    ob = super(BrowserRequest, self).traverse(obj)
  Module zope.publisher.http, line 455, in traverse
    ob = super(HTTPRequest, self).traverse(obj)
  Module zope.publisher.base, line 261, in traverse
    obj = publication.traverseName(self, obj, entry_name)
  Module zope.app.publication.zopepublication, line 197, in traverseName
    ob2 = adapter.publishTraverse(request, nm)
  Module lp.services.webapp.publisher, line 863, in publishTraverse
    nextobj = self._publishTraverse(request, name)
  Module lp.services.webapp.publisher, line 1022, in _publishTraverse
    return self._handle_next_object(nextobj, request, name)
  Module lp.services.webapp.publisher, line 893, in _handle_next_object
    raise NotFound(self.context, name)
NotFound: Object: <POFile at 0x193768d0>, name: u'0'

Request Variables top
HTTP_HOST: translations.launchpad.net
HTTP_REFERER: https://translations.launchpad.net/granite/trunk/+pots/granite/uk/2/+translate?field.alternative_language=uk&field.alternative_language-empty-marker=1
PATH_INFO: /granite/trunk/+pots/granite/uk/0/+translate
QUERY_STRING:

j.c.sackett (jcsackett)
Changed in launchpad:
assignee: nobody → j.c.sackett (jcsackett)
Revision history for this message
Curtis Hovey (sinzui) wrote :

Submissions from message sharing are used as suggestions. It is possible for the POT to loose messages, or for POFile to change suggestions, but the shared messages remain. The submission (shared message) continues to exist, but it is not in a POFile. the submission is given a zero sequence to ensure its POPO is compatible with other code that accept it. The submission an be used since we know what the text is, but it cannot be traversed to to see the context in a current POFile.

We want an attribute like .is_traversable on the POPO that returns false when the sequence is zero. Templates that link to the POFile message must check if the submission is traversable.

j.c.sackett (jcsackett)
Changed in launchpad:
status: Triaged → In Progress
Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Curtis Hovey (sinzui)
tags: added: qa-ok
removed: qa-needstesting
Ian Booth (wallyworld)
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.