1499708 - Stop using 'name' attribute in custom richlistbox binding in addons manager

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement, P3)

Description

[:Gijs (out for now; he/him)]

about:addons has a few different custom richlistbox/richlistitem bindings. The items use the 'name' attribute as the main label.

This adds complexity on the l10n side because fluent has a whitelist of localizable attributes and 'name' isn't in it.

I imagine it'll also make it harder to convert these richlistboxes to "normal" ones because of the different use of attributes.

Brian, can you clarify if we have a (detailed) plan to move richlistbox off XBL at the moment, or if that's blocked on other stuff?

Off-hand it seems like we could at least simplify this, perhaps even merge the bindings with their parents...

Comment 1

[Brian Grinstead [:bgrins]]

(In reply to :Gijs (he/him) from comment #0)
> about:addons has a few different custom richlistbox/richlistitem bindings.
> The items use the 'name' attribute as the main label.
> 
> This adds complexity on the l10n side because fluent has a whitelist of
> localizable attributes and 'name' isn't in it.
> 
> I imagine it'll also make it harder to convert these richlistboxes to
> "normal" ones because of the different use of attributes.
> 
> Brian, can you clarify if we have a (detailed) plan to move richlistbox off
> XBL at the moment, or if that's blocked on other stuff?
> 
> Off-hand it seems like we could at least simplify this, perhaps even merge
> the bindings with their parents...

AIUI there is work starting on a new about:addons UI (likely using HTML Custom Elements similarly to web payments and quantumbar), which will remove all the addon-specific XBL bindings. So my first instinct is to say: "don't spend time converting these to Fluent" since the UI will be going away soon, unless if the new design is going to use many of the same strings - in which case doing the Fluent work up front might make sense anyway. Mark, could you help detail any plans/timelines for this work, and if new designs expected to reuse the same strings that the current UI uses?

Comment 2

[Brian Grinstead [:bgrins]]

FWIW: I was just looking into using Shadow DOM for richlistbox yesterday and ran into a bug that appeared to be related to XBL insertion combined with Shadow DOM. I'm planning to get that on file this week, (hopefully today, depending on how hard it is to make a good STR).

Comment 3

[Mark Striemer [:mstriemer]]

Just discussed the plans for the new about:addons and we will likely be rewriting in HTML with a subset of the existing strings (some sections will be going away). There could be some tweaks but many of them will remain the same.

Work should be starting on the new about:addons in 65 but not for a few weeks at least. This version will be behind a pref and will match the current version quite closely.

I have a patch to add keyboard shortcuts but it is on hold while the recent about:addons changes have been landing. I can hold off on landing that until the fluent updates are done or at least are far enough along that I can convert it myself.

Updating about:addons to fluent should be helpful even with the rewrite since we can reuse the strings from fluent. If you wanted to skip some sections you can likely leave Plugins, Dictionaries and Languages as is.

Comment 4

[Mark Striemer [:mstriemer]]

I'm guessing this would just be for the categories (sidebar nav items)? I see the add-on items also use richlistitem with a name attribute but the add-on name isn't translated through fluent.

I can take a look at changing those attribute names, is this blocking some fluent work right now? My quick investigation looks like it would just affect the category names, which would be nice to get into fluent but is a pretty small subset.

Comment 5

[:Gijs (out for now; he/him)]

(In reply to Mark Striemer [:mstriemer] from comment #4)
> I'm guessing this would just be for the categories (sidebar nav items)? I
> see the add-on items also use richlistitem with a name attribute but the
> add-on name isn't translated through fluent.
> 
> I can take a look at changing those attribute names, is this blocking some
> fluent work right now? My quick investigation looks like it would just
> affect the category names, which would be nice to get into fluent but is a
> pretty small subset.

It's not blocking anything, we can work around it by using data-l10n-attrs in the markup to allow the 'name' attribute to be localized. In fact, it looks like that landed today - bug 1491679 .

So if this is essentially just waiting to be redundant-ized by the HTML version, maybe we should just close this as wontfix?

Comment 6

[Mark Striemer [:mstriemer]]

Ah, good to hear. I don't think we'll need to fix this then.