L20n/Issues: Difference between revisions
< L20n
Jump to navigation
Jump to search
No edit summary |
(platform dependent strings?) |
||
| Line 2: | Line 2: | ||
; Editors : If you know someone who should be participating in this work as an editor, please convince her or him to apply. | ; Editors : If you know someone who should be participating in this work as an editor, please convince her or him to apply. | ||
; Tools used : One part of the specification should be a grammar specification for the fileformat, in a somewhat understandable syntax. Currently, I'm using [http://antlr.org antlr] to create parsers from a EBNF-like grammar. It promised to create code for more than just java, but currently, I'm hitting a few blockers. It might be that I'm hitting bugs in the 3.0b5, or just limitations of the approach in antlr. Anyway, there's currently no descent output other than java, and creating ASTs doesn't work that well without putting AST-related constructs into the grammar. Which is merely noise. Suggestions welcome, in particular for tools that could even generate js. | ; Tools used : One part of the specification should be a grammar specification for the fileformat, in a somewhat understandable syntax. Currently, I'm using [http://antlr.org antlr] to create parsers from a EBNF-like grammar. It promised to create code for more than just java, but currently, I'm hitting a few blockers. It might be that I'm hitting bugs in the 3.0b5, or just limitations of the approach in antlr. Anyway, there's currently no descent output other than java, and creating ASTs doesn't work that well without putting AST-related constructs into the grammar. Which is merely noise. Suggestions welcome, in particular for tools that could even generate js. | ||
; Platform dependent strings : Can l20n help with doing platform-specific strings (think Options vs Preferences) for Mozilla apps? | |||
Back to [[L20n]]... | Back to [[L20n]]... | ||
[[category:L20n|Issues]] | [[category:L20n|Issues]] | ||
Revision as of 07:46, 25 March 2008
- bug tracking
- We should be able to file and track bugs. We'll start with bugs in the Mozilla Localizations product, Component Other. Make sure to CC l10n@moz on those. We'll create a structure for those bugs once we know what needs to get tracked.
- Editors
- If you know someone who should be participating in this work as an editor, please convince her or him to apply.
- Tools used
- One part of the specification should be a grammar specification for the fileformat, in a somewhat understandable syntax. Currently, I'm using antlr to create parsers from a EBNF-like grammar. It promised to create code for more than just java, but currently, I'm hitting a few blockers. It might be that I'm hitting bugs in the 3.0b5, or just limitations of the approach in antlr. Anyway, there's currently no descent output other than java, and creating ASTs doesn't work that well without putting AST-related constructs into the grammar. Which is merely noise. Suggestions welcome, in particular for tools that could even generate js.
- Platform dependent strings
- Can l20n help with doing platform-specific strings (think Options vs Preferences) for Mozilla apps?
Back to L20n...