Audit and fix any issues around translating bidirectional language pairs (RTL to LTR, or LTR to RTL)
Categories
(Firefox :: Translations, enhancement, P3)
Tracking
()
People
(Reporter: gregtatum, Unassigned)
Details
In the initial implementation, we didn't take care to make sure switching between RTL and LTR worked well. The TranslationsDocument needs to be audited for correct behavior around switching the language direction. We have Persian in Nightly, and this would be a good test language to try out these changes. We need to investigate if we need to manually adjust the directionality of inline and block elements, and if this causes breakage. It would be good to also check the behavior on other browsers for they handle this switch.
|
Reporter | |
Updated•10 months ago
|
|
|
Reporter | |
Comment 1•9 months ago
|
||
In order to ship Farsi, we should handle directionality changes. The work here is to detect if the language change also affects the directionality. If it does, then we should change the element.style.direction of the block element. This seems to give adequate results in my testing. There is some bit of directionality that doesn't change perfectly, but I think this is a fair trade-off to get better paragraph layout.
Here is where the update to updateNodesWithTranslations should go, but it should be smarter to know what to apply.
diff --git a/toolkit/components/translations/content/translations-document.sys.mjs b/toolkit/components/translations/content/translations-document.sys.mjs
index 7f436575d8f4c..f74e7d72f2371 100644
--- a/toolkit/components/translations/content/translations-document.sys.mjs
+++ b/toolkit/components/translations/content/translations-document.sys.mjs
@@ -1203,20 +1203,21 @@ export class TranslationsDocument {
}
case Node.ELEMENT_NODE: {
// TODO (Bug 1820625) - This is slow compared to the original implementation
// in the addon which set the innerHTML directly. We can't set the innerHTML
// here, but perhaps there is another way to get back some of the performance.
const translationsDocument = this.domParser.parseFromString(
`<!DOCTYPE html><div>${translatedHTML}</div>`,
"text/html"
);
updateElement(translationsDocument, node);
+ node.style.direction = "rtl";
break;
}
}
}
this.#nodesWithTranslatedHTML.clear();
this.#updateTimeout = null;
});
}
(In reply to Greg Tatum [:gregtatum] from comment #1)
The work here is to detect if the language change also affects the directionality. If it does, then we should change the
element.style.directionof the block element.
In a perfect world I would have wanted the translation engine to swap the website UI itself to RTL along with the text being translated, but alas, I think this is almost impossible to cater for every possible scenario, and there are many.
Since that's out of the question, when changing the direction of the element you inherently also align it to the right (for the RTL->LTR case), and this would not look food on all websites or UI layouts.
So additionally, I think something like text-align: match-parent would also be needed, to let the text (in the LTR->RTL case) be aligned to the left still, even though that's not "correct" for RTL users (or LTR users, for the RTL-LTR case). Having text being readable is more important than having it aligned to the correct side, I think.
Of course, this isn't a perfect solution for all cases, since I can assume there would be contexts where the parent's text alignment is not the same as the child, but I'm guessing this is a minor enough issue to let it slide.
Description
•