Mozilla Translator: Fuzzy and Status
Ricardo Palomares Martinez
As I'm testing MT 5.1 I've realized something that I had forgotten
long time ago. MT 5.1 has a Status field for every string and also a
Fuzzy on/off field.
I've never used these fields because I never really knew how they work
(and, to be honest, that's still the situation). :-) So, I'd like to
ask you for info on them, and also propose something, which is tied to
Auto-translate and Search Translation Inconsistency.
Both Update Product (for JAR based translations) and CVS Import
Directory (for CVS based translations) options present a small dialog
to select the product to update. I've thought that a "[ ] Clear all
Fuzzy values before updating" could be inserted in that dialog, so
before updating, all strings would be marked as valid, and after
updating, the new and modified ones would have again Fuzzy checked. As
a "Edit Fuzzy" option exists, that would really allow to keep a track
of pending strings to review. That would even allow to let MT
autotranslate before reviewing, enhancing translation consistency.
Also, I would be glad to know ideas about Status field, that could be
used in a very similar way.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Tsahi Asher
Translated and Perfect all have more or less the same meaning, and i
doubt if Migrated has any use.
anyway, this whole field has little use if the user can't search string
by it (e.g. find all strings who's status is Error).
auto-translate should be done carefully, sometimes the same string is
translated differently in different places, depending on context.
--
Tsahi Asher
Hebrew L10n Team
http://www.mozilla.org.il
Ricardo Palomares Martinez
> the status field IMO has way too many possible values. the Accepted,
> Translated and Perfect all have more or less the same meaning, and i
> doubt if Migrated has any use.
When you migrate a product to another one, all strings added are
marked as "Migrated". Anyway, I think Henrik Lynggaard thought of it
as a "user" field, so the program doesn't do a lot with it.
> anyway, this whole field has little use if the user can't search string
> by it (e.g. find all strings who's status is Error).
>
It could be an addition, but I really want to finish testing MT 5.1
and the more options I add, the more time I delay it. So, if anybody
really needs such a thing, please tell me now. :-)
> auto-translate should be done carefully, sometimes the same string is
> translated differently in different places, depending on context.
Yes, that's where "Fuzzy" status could come to rescue. Let's imagine
that we can be sure that, just before updating the product, all of its
strings are marked as NOT fuzzy. New and updated strings will be
marked as Fuzzy, and presented in the "Updated strings" table.
Next, we dismiss that window without editing anything on it, run
Auto-translate and then go to Edit -> Fuzzy. Auto-translated strings
will still appear, as auto-translating them don't remove the Fuzzy
flag. Time to complete and review the list.
Of course, this strategy would deserve a long testing and refinement
period, but as it is not mandatory, it only can lead to better or
equal results that our current method.
Robert Kaiser
> Next, we dismiss that window without editing anything on it, run
> Auto-translate and then go to Edit -> Fuzzy. Auto-translated strings
> will still appear, as auto-translating them don't remove the Fuzzy
> flag. Time to complete and review the list.
Why does one have to remove the fuzzy status on update? Only on editing
(or just doing a double-click into the translated column, or "un-check"
the fuzzy state), i.e. when the localizer have touched it, the fuzzy
status on a string should be unset. That the same concept as one has got
using KBabel on .po files, BTW...
Robert Kaiser
Ricardo Palomares Martinez
Because, right now, it's likely that ALL strings are marked as fuzzy,
thus forcing the localizer to walk through over the whole translation
to remove them.
Instead of giving the choice of removing Fuzzy flag on the whole
translation when updating, it could also be a separate option, but I
thought it would be a bit inconvenient.
As of unsetting automatically the fuzzy flag when the localizer (edit?
| changes?) one string, I agree. The "Edit" vs. "Change" doubt comes
to my mind because now, if you are editing phrases with the Edit
Phrase dialog, you could not change a translation and yet closing the
dialog or moving to another phrase would count as an edition.
The main point still remains, and it is if the MT users think all of
this would worth the effort. Would you really find all this
(potentially) useful?
TIA
Robert Kaiser
> Because, right now, it's likely that ALL strings are marked as fuzzy,
> thus forcing the localizer to walk through over the whole translation
> to remove them.
Only new or changed strings should get set to fuzzy at update time, right?
> As of unsetting automatically the fuzzy flag when the localizer (edit?
> | changes?) one string, I agree. The "Edit" vs. "Change" doubt comes
> to my mind because now, if you are editing phrases with the Edit
> Phrase dialog, you could not change a translation and yet closing the
> dialog or moving to another phrase would count as an edition.
Well, if the localizer has viewed the string, i.e. had an edit field for
the translation active, I think removing the fuzzy state would be OK.
Robert Kaiser
Marek Stepien
> Well, if the localizer has viewed the string, i.e. had an edit field for
> the translation active, I think removing the fuzzy state would be OK.
That's what poedit does.
--
Marek Stępień <mar...@aviary.pl>
AviaryPL - polski zespół lokalizacyjny Mozilli
http://www.firefox.pl/ | http://www.mozilla.org.pl/
Robert Kaiser
> Robert Kaiser napisał(a):
>> Well, if the localizer has viewed the string, i.e. had an edit field for
>> the translation active, I think removing the fuzzy state would be OK.
>
> That's what poedit does.
That's also what I know from KBabel, and one of the good features we can
copy from there :)
Robert Kaiser
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> Because, right now, it's likely that ALL strings are marked as fuzzy,
>> thus forcing the localizer to walk through over the whole translation
>> to remove them.
>
> Only new or changed strings should get set to fuzzy at update time, right?
>
At least for "CVS mode", that's not the case now. All strings in my
toolkit product(s) are marked as Fuzzy. I'm testing CVS mode first,
though, so it could be different for JAR mode.
>> As of unsetting automatically the fuzzy flag when the localizer (edit?
>> | changes?) one string, I agree. The "Edit" vs. "Change" doubt comes
>> to my mind because now, if you are editing phrases with the Edit
>> Phrase dialog, you could not change a translation and yet closing the
>> dialog or moving to another phrase would count as an edition.
>
> Well, if the localizer has viewed the string, i.e. had an edit field for
> the translation active, I think removing the fuzzy state would be OK.
>
So, I'll do it when I finish adding the "multiple suffixes" feature
for labels, accesskeys and commandkeys. I'll see also if adding a
Search & Replace feature is feasible without taking too long, and
that's it, no more enhancements by now. :-)
Ricardo.
Ricardo Palomares Martinez
After more reviewing, I think now that I have almost all of my test MT
products strings marked as "Fuzzy" because I have imported the
translation and doing this probably leaves the Fuzzy mark set (or
untouched). This seems sensible to me, isn't it?
However, it is a PITA to have to go through every single string to
uncheck the Fuzzy flag (or, now, go through every single string inside
the Edit Phrase dialog, which I've modified to remove the Fuzzy flag
on exiting the edited string). So, I think I'm going to add a "Clear
all Fuzzy" option so people can clean up their translation status.
I'll add a confirmation dialog to avoid critical damage. :-)
Ricardo