Support of fuzzy strings (e.g. gettext-style)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
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:/
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.
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.