Feature: Hide fuzzy controls in interface (and obsolete?)

mbi / django-rosetta

Rosetta is a Django application that eases the translation process of your Django projects

MIT License

1.07k stars 195 forks source link

Feature: Hide fuzzy controls in interface (and obsolete?) #167

Open EmilStenstrom opened 8 years ago

EmilStenstrom commented 8 years ago

We automatically remove all fuzzy strings before letting translators into rosetta because we've found that they get al confused by them. Would it be possible to add a new rosetta setting that removes the fuzzy counter on the language selection page, the fuzzy navigation tag, and the fuzzy checkbox when translating? So no fuzzy doesn't show up at all in the interface?

The same is true for the obsolete feature on the language selection page.

Is this feature a good idea?
Would you accept pull requests that accomplishes this?

mbi commented 8 years ago

Hi Emil,

so what would happen if I activated this flag and I loaded a PO catalog with fuzzy strings in it? Should the suggested fuzzy translations be displayed as empty, and thus wiped when the page is submitted?

EmilStenstrom commented 8 years ago

Good question. I see a couple of options:

Fuzzy translations are discarded like you say
Fuzzy translations are still displayed as normal. This means that there would have to be a check to see if fuzzy translations exist, and if they do they override the setting
Rosetta displays a warning that a file with fuzzy translations are loaded when fuzzy is off
Rosetta crashes with a message that fuzzy translations can't be loaded when fuzzy is off

Which one would you prefer? It doesn't really matter to me since I don't have fuzzy strings.

mbi commented 8 years ago

Well.

Option 2 is akin to saying "only display fuzzy checkboxes / filters if there are fuzzy strings in the loaded catalog." A bit counter-intuitive if you ask me, especially in the case of a translation team that sometimes sees the fuzzy UI elements, sometimes not.
Option 3 and 4 even more so: imagine a non-technical translator having to deal with sudden warnings or errors if the latest makemessages dropped fuzzy strings in the catalog. 😱

That leaves us with option 1, which essentially silently deletes (potentially perfectly valid) data.

So, yea, I'm not too keen. 😏

EmilStenstrom commented 8 years ago

About option 1: I agree that this isn't a viable option.

About option 2: I don't know the target audience for django-rosetta as well as you do, but I would imagine that few translation teams will work with one project where this option is set and one where it's not. I also think where few translators will miss fuzzy strings if they are not there because all translations don't have fuzzy strings. For those two reasons I think this is the best option.

About option 3 and 4: The same person will probably run makemessages and set the no-fuzzy setting. This means that that same person (which will not be a non-technical translator) will also be able to enforce that no fuzzy strings are ever created. In latest Django this is very easy to do:

from django.core.management.commands import makemessages

class MakemessageCommand(makemessages.Command):
    msgmerge_options = makemessages.Command.msgmerge_options + ["--no-fuzzy-matching"]

EmilStenstrom commented 8 years ago

Just for reference, this is how much simpler the interface becomes without fuzzy strings enabled. A fourth of the visual overhead for each translation string is gone: