Confirmed users
177
edits
(Update directories after l10n migration) |
(Add l10n section) |
||
| Line 226: | Line 226: | ||
* Usage: <tt>chrome://devtools/skin/images/add.svg</tt> | * Usage: <tt>chrome://devtools/skin/images/add.svg</tt> | ||
== Localization (l10n) == | |||
Similar to the other chrome sections above, we also use <tt>locale</tt> URLs in the DevTools UI to load localized strings. This section applies to <tt>*.dtd</tt> (for use as entities within XUL / XHTML files) and <tt>*.properties</tt> (for use via runtime APIs) files. | |||
We currently have two sets of localized files: | |||
* '''<tt>devtools/client/locales</tt>''': Strings used in the DevTools client (front-end UI) | |||
* '''<tt>devtools/shared/locales</tt>''': Strings used in either the DevTools server only, or shared with both the client and server | |||
=== Packaging === | |||
If you add a new l10n file (such as a new <tt>*.dtd</tt> or <tt>*.properties</tt> file), there should not be any additional packaging steps to perform, assuming the new file is placed in either of the 2 directories mentioned above. Each one contains a <tt>jar.mn</tt> which uses wildcards to package all files in the directory by default. | |||
=== Usage === | |||
Locale URLs differ somewhat based on whether they are in <tt>client</tt> or <tt>shared</tt>. While we would have preferred them to match the source tree path, the requirements of the <tt>chrome://</tt> protocol don't make that easy to do. | |||
Example: | |||
* File: <tt>/devtools/client/locales/en-US/debugger.dtd</tt> | |||
* Usage: <tt>chrome://devtools/locale/debugger.dtd</tt> | |||
Example: | |||
* File: <tt>/devtools/shared/locales/en-US/gcli.properties</tt> | |||
* Usage: <tt>chrome://devtools-shared/locale/gcli.properties</tt> | |||
= Making and Submitting a Patch = | = Making and Submitting a Patch = | ||