1491852 - [tracking] Improve pseudolocales strategy

Status: NEW

(Core :: Internationalization, enhancement, P3)

Description

[Francesco Lodolo [:flod]]

Attended the Unicode conference last week, and I think Netflix approach to pseudolocalization has some interesting insights that could help us improve our strategy.

A couple of low hanging fruits:

1) Developers didn't find the accented pseudolocale usable. They improved its readability by only inflating vowels, and accenting every other character.

The expansions is less consistent, but it makes the text more readable for developers.

2) Every pseudolocale string has opening and closing square brackets. This allows to identify truncation easily (if the string is ending with an ellipsis and not a ], that's a truncation).

More complicated:

a) Pseudolocalization is opt-out, all debug builds have it enabled by default.

b) They run the English string through machine translation, and add visual markers in the pseudolocale string showing where the shortest and longest translations would end.

I think they expand the maximum length by another 40%, but I'm not completely sure about it (otherwise, I don't know how they could show the marker, if the longest translation is longer than original+40%).

Comment 1

[Jeff Beatty [:gueroJeff]]

Could we use this as a tracker and file individual bugs for the low-hanging fruit? I'm not sure if the square brackets is a Fluent feature request, but if it is, a separate bug would be good.

As for the more complicated parts, (I've already shared these thoughts with Flod and Zibi, but figure they should be documented publicly too):

a) This would require high level support (I'm thinking Senior Director or higher). To do that, we'll need the following data points:
- How many engineers are currently using pseudol10n regularly.
- Survey data on engineering's perceptions of pseudol10n usefulness.
- Cost to fix a downstream bug that could have been caught further upstream by using pseudol10n by default (time, community resources, comms, etc.).
- Number of current downstream bugs that would be caught upstream.

I think this is definitely something we should move on, once we have the data pieces in place.

b) We'll need a strong MT story. I see our use of MT increasing in 2019, which will help here.