-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow reordering child elements in translations in DOM overlays #128
Comments
The first design principle of Fluent is Control and Isolation. In particular I'd like to highlight two statements:
I think #143 is a good first attempt of the issue. It satisfies the first statement but it breaks the second one. The developers should not have to put anything in the source code for localizers to be able to reorder elements. Instead they should write their source code in an as agnostic manner as possible. Localizers interested in reordering should be able to do so via some additional syntax or markup. For this reason, I don't think we should give child elements names but instead, allow localizers to use CSS's structural pseudo-classes to match desired elements. I'd go for something like the following to make it easy to recognize the CSS: Source:<a href="foo">foo</a> <a href="bar">bar</a> Localization:<a data-l10n-select=":last-child">bar</a> <a data-l10n-select=":first-child">foo</a>
<a data-l10n-select=":nth-child(2)">bar</a> <a data-l10n-select=":nth-child(1)">foo</a>
<a data-l10n-select=":last-of-type">bar</a> <a data-l10n-select=":nth-of-type(1)">foo</a> In code, we could use something like: let localName = sourceChildElement.localName;
let selector = translationChildElement.getAttribute('data-l10n-select');
sourceElement.querySelector(`${localName}${selector}`);
|
I have a different take on this. I think we're trying to achieve two things with DOM overlays:
The current code is pretty good at the first, but doesn't serve us well on the latter (parameters). One thing that I went for early on is that we shouldn't have positional parameters, but only named parameters. That was done recognizing that in some languages named parameters weren't a thing, and that we'd need programmers to create sometimes non-canonical boilerplate to work around that. Sadly, I don't find that verbatim in the principles, but it surely should be one, I think. In the case of DOM nodes, we have somewhat-named parameters right now, by having node names. This doesn't seem to serve us well. I'd rather see us going for full-name. In closing, I think that parameter reordering is common enough among languages that it should fall into the simple bucket, instead of the possible bucket. |
I don't understand this objection. Developers write ids and classes for theme authors to easily reach elements in their language. Seems like the same should work well for localization.
I find the CSS pseudo-classes much harder to work with than names, and they also refer to, as Pike pointed out, order, rather than names. |
I think this is a good summary of the goals, thanks. I checked back to the DOM Overlays spec from L20n and it's pretty close to the goals defined there:
I think the crucial part which you pointed at but the L20n's goals didn't, is that some elements are in fact arguments to localization. It makes sense to me to name them then. This is also closer to what I'd like these two above overlay behaviors to be explicit and separate:
Note: This design relates to #144. A translation might remove a child element from the source. Any further re-translations will not be able to find the removed element anymore. We should see if we can fix this. If not, we should consider not keeping the referential identity of the overlaid elements to make it explicit that developer cannot rely on them for the app logic. |
I meant this in the same way we don't want developers to think about whether a particular message in the UI requires plurals in other languages than the source language. However, if we consider those elements as arguments to the translation and explicitly treat them like that (and not conflate them with the allowed text-level elements), I think it's a good idea to name them. Just like we name all other arguments. |
One note - possibly for later. I think it's a bit daunting to have to write
It would be nice to have a way in the future to make Fluent "guess" which As I said, I can see it as v2 addition, but I think it would be nice to agree on that and make sure we have a way to add a feature like this in the future. wdyt? |
I agree with @Pike. |
Could we use the name as alt text in the image case? You know, to make it double duty as a11y enhancement? (And if alt name is set, don't override it to allow for exceptions) |
I'm not sure I see the value of of such special-casing. What are you trying to achieve? :) |
I'm trying to capture the value of the named attribute as some sort of fallback. We use most of our ids (be it message id, or external argument id) as a last resort meaningful feedback for the user. If we can't resolve My current concern is that asking developers to add If we can find an additional use for the I'm just trying to wear a user hat. From the user standpoint, I expect devs to want us to make the example I gave above with |
TBH, instead of creating side-effects of the feature, we should focus on what we're really doing: We sanitize HTML safely, and take a lot of l10n content markup away from developer's shoulders. I expect them to jump up and down in joy over just having to add an attribute to get their non-localizable elements and attributes into the target DOM. |
In
fluent-dom
it is currently not possible to reorder child elements found in the translation if they're of the same type. An example from bug 1424682:The text was updated successfully, but these errors were encountered: