Pontoon: Subpar matching in suggestions

[Jordi Serratosa]

Hi,

Take a look to this existintg string:

> Some websites use trackers that can monitor your activity across the
> Internet. With Tracking Protection Firefox will block many trackers
> that can collect information about your browsing behavior.
https://pontoon.mozilla.org/ca/firefox/all-resources/?string=152174

and this new string:

> Some websites use trackers that can monitor your activity across the
> Internet. In private windows Firefox Content Blocking automatically
> blocks many trackers that can collect information about your browsing
> behavior.
https://pontoon.mozilla.org/ca/firefox/all-resources/?string=189818

Pontoon does not offer any machinery suggestion. Note the differences
between the 2 strings (underlined):

> Some websites use trackers that can monitor your activity across the
> Internet. _In private windows Firefox Content Blocking automatically
> blocks_ many trackers that can collect information about your browsing
> behavior.
[the new string is untranslated so that you can see that no suggestion
is offered]

In my opinion, the existing string is a great candidate for a machinery
suggestion but alas! the translator has to retranslate the whole string
again. This is a major time waster. I've seen the same behaviour in
other strings too.

If the string is considered to be too long for Pontoon's fuzzy matching
process, please reconsider the length limit. It is precisely in long
strings where the suggestions are more welcome. In my opinion, reusing
existing translations should be a priority in Pontoon so that we do not
feel that we are retranslating the same over and over again.

salut,
jordi s

[Jordi Serratosa]

Hi,

Another area where Pontoon fails, as far as string matching is
concerned, is when the existin string is in FTL format the the new
string is not.

The following 2 strings are a 100% match, but Pontoon does not offer any
suggestion:

> Slow-Loading Trackers
Existing (FTL):
https://pontoon.mozilla.org/ca/firefox/all-resources/?string=189840
New (non-FTL):
https://pontoon.mozilla.org/ca/firefox/all-resources/?string=189388

Could this be addressed? This might cause inconsistencies, waste of time
and frustration.

salut,
jordi s

[Eduardo Trápani]

> In my opinion, the existing string is a great candidate for a machinery
> suggestion but alas! the translator has to retranslate the whole string
> again. This is a major time waster.

Yes, I know exactly what you mean. I don't now how easy it is to solve
on their side though, this is one of the bugs involved:

https://bugzilla.mozilla.org/show_bug.cgi?id=1469010

[Julen Ruiz Aizpuru]

2018-09-01 17:18 GMT+02:00 Jordi Serratosa <jordis...@gmail.com>:
>
> In my opinion, the existing string is a great candidate for a machinery
> suggestion but alas! the translator has to retranslate the whole string

> again. This is a major time waster. I've seen the same behaviour in other
> strings too.
>

I can only agree with the sentiment here; even sometimes 100% matches
are missed if they go above 255 characters [1].

Are there any plans to make fixing this a priority? It might be
obvious to say but it'd be a real time saver for translators, plus
it'd help with consistency. I hope something can be done soon to
improve the TM quality overall.

Thanks for your time put into improving Pontoon for all!

Regards,
Julen.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1468452

[Matjaz Horvat]

Hi,

Indeed, Pontoon's Translation Memory doesn't work at all for longer
strings (bug 1469010). While that affects less than 1% of all strings
in Pontoon, the longer the string, the more time can be saved using
TM. We should fix this. I'm adding it to the Q4 list:
https://wiki.mozilla.org/L10n:Pontoon#Other_bugs

The problem with complex FTL strings is harder to solve, because FTL
format cannot be fully converted to simple file formats (like TMX).
Hence, it also involves changes to the data model and UX. See bug
1453341 for details.

-Matjaž

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n

[Eduardo Trápani]

Hi Matjaž,

> Indeed, Pontoon's Translation Memory doesn't work at all for longer
> strings (bug 1469010). While that affects less than 1% of all strings
> in Pontoon, the longer the string, the more time can be saved using
> TM. We should fix this. I'm adding it to the Q4 list:
> https://wiki.mozilla.org/L10n:Pontoon#Other_bugs

I already sent a fix[1] to that bug. Do you think it could be applied?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1469010#c2

[Matjaz Horvat]

Hi Eduardo,

Thanks for your comment! Jotes looked into it and responded in the
bug. Let's continue the conversation there.

-Matjaž

[Jordi Serratosa]

Hi all,

Almost a year has passed since my message quoted below. The problem
still exists. As opposed to what I mentioned in my message, I assume it
is not a matter of FTL vs. non-FTL format. It is about FTL all the way.

6 days ago I translated this string:
https://pontoon.mozilla.org/ca/firefox/browser/browser/protections.ftl/?string=201508

Today I find the exact same string on another FTL file:
https://pontoon.mozilla.org/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395

Pontoon is not capable to suggest the string I translated 6 days ago. I
find this unacceptable under any l10n point of view.

I am aware about bug https://bugzilla.mozilla.org/show_bug.cgi?id=1453341

I am aware that the string ID is internally saved with the string and
this is probably what breaks fuzzy matching.

Even the TMX translation memories of projects that contain FTL-formatted
files include the string ID where there should only be the actual
string. This renders string reuse useless. The string ID should be added
in the TMX somewhere else allowed by the standard, but not in the
target/source fields.

Please fix your tools to allow the most basic l10n features, which are
string matching and reuse.

This is even more urgent when I, more often than not, Mozilla goes:
"Hey, we ditched this project and started a brand new Browser for
Android/iOS/Desktop/whatnot from scratch!"

Please Mozilla, fix your internal tools to our lifes easier. Fix your
tools for them to support your own(!) formats. We are all volunteering
our time, and stuff like this feels a waste of mine.

Excuse my harsh words, but this is frustrating.

salut,
jordi s

El 01/09/2018 a les 17:42, Jordi Serratosa ha escrit:
>
> Hi,
>

[Michael Bauer]

Totally with you Jordi. I was going to say more but deleted it. I
reached the "what's the point of talking" stage quite some time ago.

Michael

Sgrìobh Jordi Serratosa na leanas 21/08/2019 aig 16:33:

[Matjaz Horvat]

Hi Jordi,

I have to admit our team hasn't been very helpful in acting upon
localizers' requests recently, as confirmed by the wiki that tracks
our work:
https://wiki.mozilla.org/L10n:Pontoon

Over the past years Pontoon often found itself in a position where new
functionality had to be developed under time pressure. It looked great
from the outside, because we shipped new features regularly, but it
also hurt our codebase.

Hence we decided to take a step back and rewrite the central piece of
Pontoon - the translation workbench. This work is invisible from the
outside, because it hasn't shipped for most people yet and because it
keeps most of the UI unchanged. Even to me it sometimes appears
frustrating, because new feature development is effectivelly on hold.
But the new technology stack will allow us to develop and ship new
features more rapidly, without putting harm on our codebase.

We intend to ship the new codebase by the end of September and then
restart new feature development, starting with features requests by
localizers. Before we do so, we'd like to involve you all to help us
with prioritization.

Since TM is such an important matter, we'll make an exception and
start fulfilling this request now. Here's our action plan to improve
TM support for Fluent strings:

Step 1: Store Fluent strings in TM as they appear in the string list.
This will prevent Fluent syntax (including keys) from appearing in TMX
files and fix TM mismatching caused by different keys.

Step 2: Create separate TM entries for value and each attribute of
Fluent strings. This will further improve TM matching.

Step 3: Create separate TM entries for each selector variant of Fluent strings.

Step 1 takes the highest priority and will be addressed immediately.

We'd love to hear your thoughts on this. If the high-level plan looks
good, I'll split bug 1453341 into three pieces (one per step described
above) and then we can discus things in more detail there.

Please also note that the original bug reported in this thread has
been fixed (bug 1469010). Let us know if TM still doesn't work for you
for strings longer than 255 characters.

Thanks,
Matjaž

On Wed, Aug 21, 2019 at 10:14 PM Jordi Serratosa <jordis...@gmail.com> wrote:
>
> Hi all,
>
> Almost a year has passed since my message quoted below. The problem
> still exists. As opposed to what I mentioned in my message, I assume it
> is not a matter of FTL vs. non-FTL format. It is about FTL all the way.
>
> 6 days ago I translated this string:
> https://pontoon.mozilla.org/ca/firefox/browser/browser/protections.ftl/?string=201508
>
> Today I find the exact same string on another FTL file:
> https://pontoon.mozilla.org/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395
>
> Pontoon is not capable to suggest the string I translated 6 days ago. I
> find this unacceptable under any l10n point of view.
>
> I am aware about bug https://bugzilla.mozilla.org/show_bug.cgi?id=1453341
>
> I am aware that the string ID is internally saved with the string and
> this is probably what breaks fuzzy matching.
>
> Even the TMX translation memories of projects that contain FTL-formatted
> files include the string ID where there should only be the actual
> string. This renders string reuse useless. The string ID should be added
> in the TMX somewhere else allowed by the standard, but not in the
> target/source fields.
>
> Please fix your tools to allow the most basic l10n features, which are
> string matching and reuse.
>
> This is even more urgent when I, more often than not, Mozilla goes:
> "Hey, we ditched this project and started a brand new Browser for
> Android/iOS/Desktop/whatnot from scratch!"
>

> Please Mozilla, fix your internal tools to our lifes easier. Fix your
> tools for them to support your own(!) formats. We are all volunteering
> our time, and stuff like this feels a waste of mine.
>
> Excuse my harsh words, but this is frustrating.
>
> salut,
> jordi s
>
>

> El 01/09/2018 a les 17:42, Jordi Serratosa ha escrit:
> >
> > Hi,
> >
> > Another area where Pontoon fails, as far as string matching is
> > concerned, is when the existin string is in FTL format the the new
> > string is not.
> >
> > The following 2 strings are a 100% match, but Pontoon does not offer
> > any suggestion:
> >
> >> Slow-Loading Trackers
> > Existing (FTL):
> > https://pontoon.mozilla.org/ca/firefox/all-resources/?string=189840
> > New (non-FTL):
> > https://pontoon.mozilla.org/ca/firefox/all-resources/?string=189388
> >
> > Could this be addressed? This might cause inconsistencies, waste of
> > time and frustration.
> >
> > salut,
> > jordi s
> >
> >

[Matjaz Horvat]

Hi Jordi and everybody,

We went ahead and filed a bug to track Step 1:
https://bugzilla.mozilla.org/show_bug.cgi?id=1576120

It has already been fixed and depoyed to stage.

The string you mentioned now gets suggested as expected:
https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/protections.ftl/?string=201508
https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395

The TMX file also no longer contains string identifiers.

We plan to deploy the patch to production server on Monday.

Let us know if you have any thoughts!

Thanks,
Matjaž

[Julen Ruiz Aizpuru]

Hau idatzi du Matjaz Horvat (mat...@mozilla.com) erabiltzaileak (2019
abu. 23, or. (18:00)):

>
> Hi Jordi and everybody,
>
> We went ahead and filed a bug to track Step 1:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1576120
>
> It has already been fixed and depoyed to stage.
>
> The string you mentioned now gets suggested as expected:
> https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/protections.ftl/?string=201508
> https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395
>
> The TMX file also no longer contains string identifiers.
>
> We plan to deploy the patch to production server on Monday.
>
> Let us know if you have any thoughts!

Thanks for finally taking action on this.

As Jordi and Michael already mentioned, TM in Pontoon has resulted in
a quite frustrating experience, and I really hope the subsequent fixes
also happen in a timely manner.

Regards,
Julen.

[Matjaz Horvat]

Hi Julen,

Sorry it took so long. :/ We most certainly underestimated the
importance of this bug.

We just deployed the first patch (AKA Step 1) to production server. It
should make the TM experience for all Fluent strings that appear in
the regular editor seamless.

We'll address the following two steps (which affect <0.5% strings)
after we ship Translate.Next.

-Matjaž

[Jordi Serratosa]

Hi Matjaz,

Thank you for dealing with it, much appreciated. About this:

> We plan to deploy the patch to production server on Monday.

I understand that should have been Monday 26th...?
I'm not yet getting any suggestion for:
https://pontoon.mozilla.org/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395

Is the patch already in production?

What I realised is that TMX download no longer includes FTL stringIDs
source/targets. Thank you!

salut,
jordi s

El 23/08/2019 a les 18:00, Matjaz Horvat ha escrit:
> Hi Jordi and everybody,
>
> We went ahead and filed a bug to track Step 1:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1576120
>
> It has already been fixed and depoyed to stage.
>
> The string you mentioned now gets suggested as expected:
> https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/protections.ftl/?string=201508
> https://mozilla-pontoon-staging.herokuapp.com/translate/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395
>
> The TMX file also no longer contains string identifiers.
>
> We plan to deploy the patch to production server on Monday.
>
> Let us know if you have any thoughts!
>

[Matjaz Horvat]

Hi Jordi,

The patch is indeed already in production.

But it turns out we have another bug (unrelated to Fluent), which can
prevent best TM matches to appear in Machinery:
https://bugzilla.mozilla.org/show_bug.cgi?id=1578155

The patch is already in place, waiting for a review:
https://github.com/mozilla/pontoon/pull/1367

I'll let you know once it's deployed to prod, should be shortly.

Sorry for inconvenience!

-Matjaž

[Matjaz Horvat]

Hi again,

Thanks to Jotes and his fast review, the patch has now been deployed to prod.

Jordi, you should see the 100% match now:
https://pontoon.mozilla.org/translate/ca/firefox/browser/browser/preferences/preferences.ftl/?string=201395

This patch should improve our TM matching in general, but it's hard to
tell by how much.

-Matjaž

[Jordi Serratosa]

It works now! Thank you, Matjaž and Jotes!

salut,
jordi s