Firebug is using BabelZilla to utilize an existing community of localizers and get translation to various languages. This effort requires a process and Firebug developers should follow some rules that help to synchronize files coming from BZ to the development source tree.
In case of any problems related to wrong usage of translated string within the Firebug's UI, please report a new issue.
- FB developers should change only the en-US locale files, which stand like a
template for all other translated locales.
- If some string (its value) is changed, change also its key so, translators can see
there is something new to translate.
- When updating from BZ, always get all translations (even for not released
locales) from BZ before uploading new version. So, no translation made since the last upload is lost. The only dir, which is *not* synced with BZ is locale/en-US.
- Only *.properties files should be used for localization (Firebug doesn't want to use DTD file due a lack of script-ability)
There are several APIs that are be used to make Firebug code localizable.
- $STR - localization of a static string.
- $STRF - localization of a string with dynamically inserted values.
// Search for key "Label" within firebug *.properties files and returns its value. // If the key doesn't exist returns "Label". $STR("Label");
// Search for key "Button_Label" withing the firebug *.properties files. // If the key doesn't exist returns "Button Label". $STR("Button Label");
// Search for key "net.Response_Header". // If the key doesn't exist returns "Response Header". $STR("net.Response Header");
var param1 = 10; var param2 = "ms"; // Returns "Request Time: 10 [ms]" for key that looks as follows: // net.timing.Request_Time=Request Time: %S [%S] $STRF("net.timing.Request Time", param1, param2);
In order to register a new string bundle (*.properties file) use
Firebug.registerStringBundle method. This method should be also used from within a Firebug extension so, Firebug localization API properly work.