Do not sort output from

Bug #520986 reported by Rail Aliiev on 2010-02-12
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Данило Шеган

Bug Description

This is a duplicate bug originally reported by Dwayne Bailey here:

Running intltool-update on various files results in the translation
strings being sorted.

This creates a problem for translation as the file is following a system of:


The result is that the connection between name and description is lost and a
translator cannot infer information from the description to help translate a
cryptic name.

A simple hack to remove the sorting results in a order that doesn't represent
the order of the underlying file either.

Attached is a simple patch which solves the problem.

Related branches

Rail Aliiev (rail) wrote :

There should be no need to introduce a new dependency for this feature. Also, we should probably keep the sorting in, but do it on the source file location, just like xgettext does anyway.

Changed in intltool:
status: New → Triaged
importance: Undecided → Low
Claude Paroz (paroz) wrote :

Mmmh, if only my Perl skills were better :-/ Could this bug get higher priority?

Claude! You are joking right?

This bug has been relegated to forgotten wherever it is reported, even when it comes with a patch. The most response it ever got was for a coder to painfully, and badly, explain why it wasn't a bug.

The irony for me is that this bug so severely impacts localisation quality it makes me wonder about two things 1) Are programmers at all qualified to evaluate the importance of localisation bugs, 2) How much rubbish localisation must be out there if translators are translating with zero context information.

AsstZD (eskaer-spamsink) wrote :

Yes, we definitely need such cludges, because... programmers cannot move their lazy butts and (gasp!) actually document what a string means! Writing comments is hard...

Giving it a higher priority would not help much since we have very limited time to work on these bugs. I'd be very delighted to get a complete patch which doesn't introduce a new dependency, and ensures all the tests are updated, and at least some exercise the sorting of messages. Ideally, it'd sort by *real* source reference, but I would not insist on that to solve the bug (because that'd be much harder with the intltool framework which actually lets xgettext extract messages from generated .h files).

Daniel Macks (dmacks-netspace) wrote :

Tie::IxHash does look like a useful way to handle this internally. That module's licensing is "same terms as Perl itself", which is an option of Artistic or GPL, and intltool is GPL also. Therefore, it seems permissible to include the module code directly in intltool itself. The Tie::IxHash module is just a single .pm file (~400 lines of code), so could just bundle that file with an appropriate installer directive (or maybe only do it conditional on the system not't have the module already available?). Or else just copy the code into directly into

Daniel Macks (dmacks-netspace) wrote :

Looking at the specific uses of %messages, it would be pretty easy to hack together a poor-man's Tie::IxHash right in this one script, since all you need to do is store/retrieve by key and generate a sorted list of keys (not need to delete, take slices, etc.). I'll try to take a look in a few days.

Indeed, it should be quite simple to provide just the needed functionality. Thanks for looking into it, and I look forward to a patch :)

Changed in intltool:
milestone: none → 0.42.0
assignee: nobody → Данило Шеган (danilo)

Seeing how no progress has been made on this, I'll be working on this today.

Changed in intltool:
status: Triaged → In Progress

Fixed in r721 of lp:intltool, please test.

Changed in intltool:
status: In Progress → Fix Committed
Changed in intltool:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers