Implement fuzzy string handling
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Since the Blueprint to "https:/
Please please please implement this!
It is really lots of wasted time and efforts to retranslate strings again and again only because there have been typo fixes.
I did a string cleanup some days ago for josm and changed probably about 100 strings adding dots at end or change case of some words. This usually does not affect the translations, but when we have 20 languages and 100 strings this means translators need to retranslate 2000 strings from scratch and only because some dots have been changed.
The 100 changed strings are probably exceptional, but such cleanups and typo fixes are common and if I sum up such minor changes, than 50-100 strings a month are probably normal for josm. This means 1000 to 2000 retranslations each month. This is discouraging translators.
This is no minor issue, this is really a major drawback of Launchpad compared to the other gettext systems.
Dirk, thanks for this report. The linked blueprint is pretty much outdated (especially the private wiki page), and the main problem for implementing something like this today are performance concerns. As such, this is a big item, and until we actually define units of work that need doing, we usually prefer to keep them only as empty blueprint placeholders. That's why I am invalidating this bug, but read on to see how we'll raise importance of any particular item.
We're just having 3.0 released today, so we'll be starting with a new prioritization process for Launchpad 4.0 development. This is a chance for us to start on new big features (such as this one) as well. I've emailed you privately about this, because I believe you should be one of our "stakeholders". A process we are implementing will allow us to keep as many people as possible happy while continuing to receive our salaries :)