display differences from upstream

Bug #32471 reported by Dafydd Harries
54
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Medium
Данило Шеган

Bug Description

  severity wishlist
  milestone future
  done

It should be easy for a translator see, for a particular PO file:

 - how many translations diverge from upstream
 - which translations diverge from upstream

Changed in rosetta:
status: Unconfirmed → Confirmed
Revision history for this message
Jannick Kuhr (jakuhr-deactivatedaccount) wrote :

I strongly support this idea, because it helps to fix many of the problems occured in the last months.

Changed in rosetta:
importance: Wishlist → Medium
Revision history for this message
Nafallo Bjälevik (nafallo) wrote :

Are we there yet? Or rather, are there anyone working on this in their branch?

Changed in rosetta:
assignee: nobody → danilo
status: Confirmed → In Progress
description: updated
Revision history for this message
Luca Ferretti (elle.uca) wrote :

May I suggest "reset translations to upstream" too?

If I'm right, Rosetta tends to ignore upstream translations of a message when you translate this message in Rosetta. This is not so good.

Example
 1. The package "foo" provides the translatable message "_Open File...",
 2. Bill, ignoring rules and guidelines for Italian translators, translates it in Italian language as "Apri File (_O)" in Rosetta.
 3. John provides the correct translation in upstream ("_Apri file...")

Based on my past experience trying to upload GNOME upstream translations, what you translate in Rossetta, stays on Rosetta. In (timeline) example, the correct translation at point 3 will never appear in Rosetta, unless you manually enter, replacing the one at point 2. Same occurs if you change a translation in Rosetta and the same will later changed in upstream.

So I think a "Reset" feature could be good: when the upstream translation is better then the one in Rosetta, you should be able to forget it, not replace.

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

Fixed in RF 4338.

Changed in rosetta:
status: In Progress → Fix Committed
Revision history for this message
Данило Шеган (danilo) wrote :

Luca, I don't want to provide automatic, no questions asked feature that will reset all translations to packaged ones like that.

The reason is simple: there might be one small fix in the entire PO file, and if we provided automatic 'revert all', people would prefer that over actually looking at what needs to change, and what doesn't. The advantage of Launchpad Translations is that you can fix translations more easily, and they will be available in Ubuntu with the next language pack update, and I don't want to lose that advantage.

I think forcing translators to go through review once and revert translations is not too bad, because if you revert them once, they'll automatically use future package/upstream updates.

So, I'd say the proper fix to the problem is:
 1. provide a list of modules with changed translations (check, look for blue bar on https://translations.launchpad.net/ubuntu/feisty/+lang/it)
 2. provide filter for looking at only those messages with such changed translations (check, this bug)
 3. put more emphasis on translation coming from the package (bug #81681), so it's easier to revert to

Revision history for this message
Luca Ferretti (elle.uca) wrote :

> Luca, I don't want to provide automatic, no questions asked feature
> that will reset all translations to packaged ones like that.

Yeah, of course. The function “reset” that I had in mind was per-message, not per-module

> So, I'd say the proper fix to the problem is:
> 1. provide a list of modules with changed translations (check,
> look for blue bar on https://translations.launchpad.net/ubuntu/feisty/+lang/it)
> 2. provide filter for looking at only those messages with such changed translations
> (check, this bug)

BTW could also interesting a filter to show only messages added in module, for example, the "About Ubuntu" appearing in gnome-panel

Revision history for this message
Claude Paroz (paroz) wrote :
Revision history for this message
Luca Ferretti (elle.uca) wrote :

@Claude

Maybe there are no changed messages :-)

Revision history for this message
Bruno (bruno666-666) wrote : Re: [Bug 32471] Re: display differences from upstream

2007/6/21, Claude Paroz <claude@2xlibre.net>:
> Mmmmh... should have landed with 1.1.6, but the "changed in Launchpad" option doesn't show any string in any package.
> https://translations.launchpad.net/ubuntu/feisty/+source/gnome-desktop/+pots/gnome-desktop-2.0/fr/+translate?batch=10&show=changed_in_launchpad
> https://translations.launchpad.net/ubuntu/feisty/+source/gnome-screensaver/+pots/gnome-screensaver/fr/+translate?batch=10&show=changed_in_launchpad
>

That's strange, there's blue bars showing there was changes in launchpad.

It seems that it doesn't work if the po files have been re-upload in Rosetta?

--
Bruno

Changed in rosetta:
status: Fix Committed → Fix Released
Revision history for this message
Claude Paroz (paroz) wrote :

Danilo,
You didn't answer to my last comment. What's the problem with this functionality? Why can't I see the changed strings in French? Does it only apply to future changes?

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

Claude, it's an interesting case I'll need to look into. It seems the counting function is wrong (which results in blue bars on the language page), since I've compared the PO file with the one downloaded from l10n.gnome.org, and could see no difference. Can you confirm that there are indeed no changes from the upstream?

So, this might be a different bug that the stats for PO files are incorrect with regards to 'changed' count.

Revision history for this message
Claude Paroz (paroz) wrote :

You're right Danilo. Apart from minor formatting differences, the msgstr content is identical between the two files (upstream and Ubuntu). So the problem is probably with the algorithm of calculating the "changed" strings.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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