Support of fuzzy strings (e.g. gettext-style)

[Dirk Stöcker]

Although in bug #312476 it is said fuzzy gettext strings will not be supported I did not find an open bugreport for that whole topic, so I open a new bug. This old bug says that https://blueprints.launchpad.net/rosetta/+spec/rosetta-fuzzy-merge is planned, but this is not implemented yet.

My suggestion would be following:

When not-yet-translated translations are displayed, then strings matching the fuzzy algorithm of gettext (or another finer newer algorithm) should be displayed as fuzzy (i.e. like a suggestion but not persistent). There is no need to support fuzzy's for already translated strings.

This infrastructure can also be used in future and improvements on the "fuzzy" algorithm would be transparent. As A start the easy gettext algorithm would be much better than nothing.

Pro: No database handling and storing of fuzzy stuff necessary (maybe temporaray storage).
Contra: Needs runtime requirements to find strings. I do not know the infrastructure enough to say if this online-fuzzying is possible or if pre-calculations are required.

Anyway there should be a way to have fuzzy strings. Retranslating larger strings only because of typo fixes in original is lots of wasted work.

[Данило Шеган (danilo)]

Hi Dirk, thanks for the report. We will be implementing the blueprint you found yourself. For whatever algorithm we choose to use, bigger concerns will be performance and infrastructure, so using gettext algorithm (which is mostly very basic) would not do us much good.

Also, for any bigger feature, we like to use blueprints to track work (we can schedule them just like bugs, yet they are not really bugs). Thus, I am marking this as "Won't fix", because we won't do this specifically, but we still have plans to implement similarity matching when offering suggestions. We'll be discussing the timeframe later, but we know it won't happen before August.

[SirVer (sirver)]

Sorry to bump all those bugs... but this feature is so crucial and no updates on any of them. Only invalidated bug reports that are pretty valid in my eyes.

[Данило Шеган (danilo)]

SirVer, it's not helpful to bump them all at all. I've had three emails to read with basically the same stuff. Since Launchpad is open source, you can help get this resolved yourself. If you are ready to invest some time to do this, come and find me on IRC (note, it's going to be significant work, though nothing too hard, just a lot of it).

Look at https://dev.launchpad.net/ to read on how to start with contributing to Launchpad.

PS. Bug is not "invalidated", but instead "won't fix" which indicates they are valid bugs but we won't be fixing it (usually due to lack of time or because we have it tracked elsewhere, like a blueprint in this case).