Re: Pontoon: Subpar matching in suggestions

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 <[email protected]> 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
> >
> >
> _______________________________________________
> dev-l10n mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-l10n
_______________________________________________
dev-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-l10n