Re: [Django] #10852: Add no-fuzzy-matching option to makemessages
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: SVN
Internationalization | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by EmilStenstrom):
* ui_ux: => 0
* type: => Uncategorized
* severity: => Normal
* easy: => 0
Comment:
Replying to [comment:4 mtredinnick]:
> "However, it should be kept in the PO file because it saves translators
work, particularly in the update phase, as they can see what a likely
match is going to be"
I've seen many instances where translators are confused by the "almost
correct" versions of strings, and instead miss them entirely. We've had
greater success when manually going through the translation files and
removing all the fuzzy strings entirely. For this reason, I'm strongly in
favour of a flag for disabling fuzzy strings.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Internationalization | Resolution:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => reopened
* resolution: wontfix =>
Comment:
Replying to [comment:5 EmilStenstrom]:
> Replying to [comment:4 mtredinnick]:
> > "However, it should be kept in the PO file because it saves
translators work, particularly in the update phase, as they can see what a
likely match is going to be"
>
> I've seen many instances where translators are confused by the "almost
correct" versions of strings, and instead miss them entirely. We've had
greater success when manually going through the translation files and
removing all the fuzzy strings entirely. For this reason, I'm strongly in
favour of a flag for disabling fuzzy strings.
I second that. Our translator actually asked me to disable fuzzy, saying
"django probably has a way to turn that off". He didn't elaborate, but
said fuzzy has caused havoc for them in the past on other projects. Since
this isn't an option, I'll be removing the fuzzy translations manually,
before sending them off.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Component: | Version: SVN
Internationalization | Resolution: wontfix
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: reopened => closed
* resolution: => wontfix
Comment:
Please do not reopen a ticket closed by a core committer, unless you have
either a good new argument (and "fuzzy has caused havoc in the past" is
certainly not) or after discussing it on django-dev mailing list.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by anonymous):
Just wanted to chime in with a "me too".
Replying to [comment:3 ramiro]:
> Exactly, the entries marked as fuzzy by `msgmerge` are generated by a
simple lexicographic comparison and the probability of them being not
totally accurate is high
At least in my case, this is just not true. It's filling things in that
are similar but not the same, and it shouldn't be. I'd rather they be
empty than speculatively filled in.
There are already many options available for makemessages. I really don't
see the harm in adding another option.
For now, I'm patching Django locally, which I really hate to do.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: wontfix => duplicate
Comment:
Duplicate of #18714.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by ramiro):
* resolution: duplicate => wontfix
Comment:
Restoring ticket status. Sorry for the noise.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: chris@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by internaut):
I stumbled upon this discussion because "fuzzy" entries in the PO files
caused big problems for me, too. I mean, "fuzzy" is ''way'' to fuzzy in
makemessages. Some examples: The string "has geolocation" gets a fuzzy
match to the string "Translation". "Further description" is believed to be
the same as "Add an inscription". "edit" is supposed to be the same as
"edition". It's just ridiculous. Because Django doesn't have a "non-fuzzy"
option for makemessages, I ended up hacking
''./core/management/commands/makemessages.py'' and adding ''-N'' to the
list of msgmerge arguments on line 197. I honestly don't understand why no
option to disable fuzzy matching is added to makemessages.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by claudep):
It's not ridiculous, it's fuzzy matching. It helps the translator ~80% of
the time, and ~20% of the time it's completely wrong. But it doesn't
matter that much because fuzzy strings are not included in compiled
messages. So it's the translator's work to evaluate accuracy of the fuzzy
proposal, and simply dismiss it when it does not make sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by sergeykolosov):
Those still looking for an option to customise `msgmerge` arguments, have
a look at changes introduced in
https://github.com/django/django/commit/06efeae598c6dafbe56d2ea323a0dccdd5bf2b8e
(Django 1.7 and above); now it is feasible by subclassing the
`makemessages` command, and overriding `msgmerge_options`.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: charettes (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Component: | Version: master
Internationalization |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: wontfix =>
Comment:
I also don't like the "fuzzy" keyword and I spent hours in deleting them
from our django.po files after running makemessages. I would like to
disable them completely since they don't make sense in our project. Every
time after running makemessages I have to search for the "fuzzy" keywords,
delete them and also delete translations which are incorrect. I would like
all the translations to be blank if not exactly translated.
I'm reopening this ticket since it's 10 years and I think it's important.
I didn't understand what you mean by "msgmerge with the "-N" option
swiches off fuzzy-matching.".
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: new
Component: | Version: master
Internationalization |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by אורי):
* cc: אורי (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:17>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Please see TicketClosingReasons/DontReopenTickets.
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: graham.carlyle@… | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: master
Internationalization |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by אורי):
OK, I created my own make_messages command:
https://github.com/speedy-net/speedy-
net/blob/staging/speedy/core/base/management/commands/make_messages.py
--
Ticket URL: <https://code.djangoproject.com/ticket/10852#comment:19>