Jetpack/Features/Localization
Jetpack features include HTML5 files with locale-specific strings. The strings need to be localizable.
The Mozilla platform supports localizing XUL and XHTML files via DTDs, but it doesn't support localizing HTML5 files that way.
Jetpack feature developers prize HTML5 and want to keep using it. They fear XHTML's extant restrictions and future stagnation.
Localizers, on the other hand, value the existing support for localizations, around which they have built toolchains.
So we want a way to localize HTML5 pages that reuses as much of the platform's existing localization support as possible.
Proposal
We implement a stream converter that processes streams of Jetpack feature HTML5 files as they are being loaded, replacing string references with localized strings. Files that wish to be localized identify themselves via a [file extension, sniffable initial string].
The converter loads localized strings from string bundles (.properties files) identified by the HTML5 files.
The syntax for identifying string bundles and referencing strings is [entity references (&reference;), mustaches ({{reference}}), dollarinkles (${reference})].
Misc
We considered implementing a custom protocol like l10n:, but doing so presents a couple of issues:
- There are security restrictions on content from the custom protocol loading content at other protocols, like resource: or chrome: (f.e. to reference scripts, images, and other files that should not be localized).
- Developers want to use JavaScript libraries like jQuery. asuth and jrburke have previously used jQuery in HTML5 files at resource: URLs, and they worked fine. But jQuery assumes URLs succeed the scheme part with slashes, so any custom protocol we implement would have to include such slashes to be jQuery-compatible.
