Closed Bug 595815 Opened 10 years ago Closed 4 years ago

<stringbundle>'s L20n support

Categories

(Core :: XBL, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: zbraniecki, Unassigned)

References

Details

Attachments

(1 file)

In order to replace .properties we should provide an equivalent of <stringbundle> tag for L20n.

The approach here is to extend current <stringbundle> tag to support .j20n/l20n files.
Blocks: 595812
Status: NEW → ASSIGNED
Attached patch patch v1Splinter Review
Patch v1, depends on bug 595816
Attachment #474697 - Flags: feedback?(l10n)
Depends on: 595816
Comment on attachment 474697 [details] [diff] [review]
patch v1

return this.stringBundle.getValue(aStringKey, 1); seems to be an awkwardness of the API over there. No idea what the 1 should be good for.

this.src.search('.j20n')!==-1 should probably really check the extension. Though I'm not too fond of the idea to use filenames as the criteria here.

Are the APIs of stringbundle really such that we want them to be compatible, or is that just so that you can migrate the code over easier? Maybe we should have "a right API" and some shims between that and the old stringbundle api.
Attachment #474697 - Flags: feedback?(l10n) → feedback-
(In reply to comment #2)
> return this.stringBundle.getValue(aStringKey, 1); seems to be an awkwardness of
> the API over there. No idea what the 1 should be good for.

Yea, minor one, it'll get fixed with the next patch for intl/l20n.

> this.src.search('.j20n')!==-1 should probably really check the extension.
> Though I'm not too fond of the idea to use filenames as the criteria here.

I do agree, but wasn't sure what can we do for filetype detection.

> Are the APIs of stringbundle really such that we want them to be compatible, or
> is that just so that you can migrate the code over easier? Maybe we should have
> "a right API" and some shims between that and the old stringbundle api.

I think of it as a form of POC - it proves the case, we can provide L20n through stringbundles and we can even make it mimic the old behavior.

We can end up with a totally different <stringresource/> tag with a completely new API. I'd love to hear from you what such API should be like. For me stringbundle is becoming pointless if we can just expose document's l20n resources to JS, but I wanted to get back to this when I'll be working on API's.
Seven years later, we're making another attempt to refactor our l10n layer.

The new tracking bug is bug 1365426 and I'll mark the previous effort as "INCOMPLETE".
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.