1385544 - Add mozl10n: protocol

Status: RESOLVED WONTFIX

(Core :: Internationalization, enhancement, P3)

Description

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

As per bug 1365031 comment 17, we're going to add a new protocol for l10n resources used by L10nRegistry.

Comment 1

[Axel Hecht [:Pike]]

As I laid out in bug 1365031 comment 18, I think the l10n registry and a protocol handler don't go together.

The l10n registry doesn't get resource names or resource locators from the developer. No URNs nor URLs. The reason behind that is that the developer doesn't actually specify resources, but something like a relative resource pattern. Out of that, the registry creates a sequence of resources, which have a locator and can be individually loaded.

But all of that is internal to the l10n registry, and opaque to anything outside of it.

As nobody ever sees those resource locators, we shouldn't create an abstraction for them.

Comment 2

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

We need some way to retrieve the data from different sources.

The resources currently available via resource://gre/localization, resource://app/localization and the ones stored in language packs.

Since :bsmedberg would like us to move away from using Chrome Registry resource entries for registering paths to langpack resources, we'll need some other protocol to do that.

Why not mozl10n: ?

What else do you suggest that we do?

Comment 3

[Axel Hecht [:Pike]]

Keep using the chrome registry as long as we still have code that uses the old gecko l10n infra. We'd need to reimplement the chrome registry otherwise, probably on a bug-compatible level.

The way to get rid of the chrome registry is to convert all call-sites to the l10n-registry-based l10n apis.

Comment 4

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

Axel, that answers the part of handling old l10n API (StringBundle/DTD).

mozl10n: protocol is :bsmedberg's idea to facilitate the new l10n API as far as I understand.

L10nRegistry has to somehow retrieve resources from langpacks. 
Currently, the only way to do this is for the WebExtensions API to register a resource entry like "resource langpack-pl ./path" and then L10nRegistry does fetch("resource://langpack-pl/path").

Comment 5

[Axel Hecht [:Pike]]

Then we don't use the resource:// protocol but file: or jar:? Like, the registration stuff would only redirect to either of those protocols, too.

Comment 6

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

Thanks!

I tried to summarize the positions in bug 1365031 comment 20. I hope I represented yours accurately!
Let's keep the conversation on the design of the langpacks there since there are tradeoffs to be made beyond just the protocol decision :)

I'll put this bug on hold until any decisions are made.

Comment 7

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

Resolving as WONTFIX. We went for a different approach