1621700 - Windows Default Browser Agent - Phase 2 - Windows 10 toast notification l10n/localization support

Status: RESOLVED DUPLICATE of bug 1854425

(Toolkit :: General, enhancement)

Description

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

This ticket tracks working through the details around localizing the Windows 10 toast notifications implemented by Bug 1621696.

Technically it's not clear how much flexibility we have. The dream would be to ship Fluent files and dynamically process strings according to the user's OS locale and/or "controlling profile" locale settings. The Fluent part is hard 'cuz we're not inside Gecko; the OS locale/"controlling profile" locale is hard 'cuz we would struggle to have deep profile integration and we have limited ability to dynamically fetch new localizations, etc.

So we'll probably end up with strings determined at build time, perhaps as an INI file for easy consumption.

Comment 1

[Axel Hecht [:Pike]]

Looking at the patches on try, there's a couple of problems.

Using INI as a file format is an unfortunate choice. They're badly defined in general, and the status quo of their usage in Firefox is like so:

• crashreporter has one parser
• CrashReport.jsm uses another parser on the crashreporter files
• updater has a different parser

updater and crashreporter parse differently for sure.

The patch on try uses GetPrivateProfileStringW, which is a WIN16 API, afaict, and it'd introduce yet another parser.

And the l10n toolchain uses yet two more parsers.

If you thought that .dtds were ugly ...

Generally speaking, an INI-based approach might need a rewrite at some point, at least if we decide to stop paying for a repack per language.

If you're choosing to go for it for now, you'll need to be aware that this code path is untested so far, and you'll need to do some testing via google translate and local repacks or such.

I'd love for this to be able to use Fluent right away, but we only have FFI for Bundles so far. If we'd invest into something that can be used by this exe, but also crashreporter and updater, maybe we should build a shared lib?

All that aside, did you validate that RTL languages work as expected?

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

For Fluent use, if you're ok with plugging Rust code, we are going to switch Firefox to use fluent-fallback and l10nregistry-rs there.

Those two could be plugged into any binary and for a small one like this, we could even simplify l10nregistry to use fluent-resmgr instead if we didn't plan to support overrides like langpacks in this binary.

You can track my progress in maturing those libraries as I get them ready for use in Firefox in bug 1613705. I could help someone working on this binary plug them into it.

Comment 3

[Robin Steuber (she/her) [:bytesized]]

I'd like to move this discussion to bug 1621696, as that is where I am posting the patches for this.

Pike- I'll respond to your post on Phabricator.
Zibi - I'm not sure whether or not that would work well for this. I'd be happy to talk about it further.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

Zibi - I'm not sure whether or not that would work well for this. I'd be happy to talk about it further.

Sure, I'm happy to advise as I'm maintaining fluent-rs library and worked on integrating it into Gecko (which was similar FFI).

Comment 5

[Nick Alexander :nalexander [he/him] (PTO Feb 24-March 3)]

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #2)

For Fluent use, if you're ok with plugging Rust code, we are going to switch Firefox to use fluent-fallback and l10nregistry-rs there.

Those two could be plugged into any binary and for a small one like this, we could even simplify l10nregistry to use fluent-resmgr instead if we didn't plan to support overrides like langpacks in this binary.

You can track my progress in maturing those libraries as I get them ready for use in Firefox in bug 1613705. I could help someone working on this binary plug them into it.

Each of these "Firefox sidecar" projects -- crashreporter, updater, browser agent -- would like to consume a small library with a very simple API. That is a noble goal but shouldn't block Kirk's work. Since Kirk was careful to not introduce a new parser (we're using the existing updater.exe one) so we're not making the existing situation worse and we don't really impact the future transition: if we can use such a library in the updater, we can use it in the browser agent.

So: yes, we'd like to do this; but we shouldn't make this work contingent on that side mission.