1,035
edits
L10n:Localization Process: Difference between revisions
→Getting started
No edit summary |
|||
| Line 22: | Line 22: | ||
Your first step is to try to find other community members already working on localization or willing to help out. You should find them on the [[L10n:Teams]] page, which lists the teams by [http://en.wikipedia.org/wiki/Language_code language code]. If there is not a team yet, please create a wiki page in the L10n:Teams category introducing yourself, following the examples set forth in the other pages. | Your first step is to try to find other community members already working on localization or willing to help out. You should find them on the [[L10n:Teams]] page, which lists the teams by [http://en.wikipedia.org/wiki/Language_code language code]. If there is not a team yet, please create a wiki page in the L10n:Teams category introducing yourself, following the examples set forth in the other pages. | ||
The easiest way to expose your localization work to users and testers is to create, what we call a language pack, within our [https://addons.mozilla.org AMO] Add-on infrastructure. By following this route of development you get all the benefits that AMO brings: you don't have to worry about hosting costs, AMO will serve updates to your language pack to your users when they get public, you can create a nice description for your language pack, and in your language, too. | The easiest way to expose your localization work to users and testers is to create, what we call a language pack, within our [https://addons.mozilla.org AMO] Add-on infrastructure. By following this route of development you get all the benefits that AMO brings: you don't have to worry about hosting costs, AMO will serve updates to your language pack to your users when they get public, you can create a nice description for your language pack, and in your language, too. Your language pack will continue to work during minor updates, because we're not changing our language strings on stable releases. | ||
The negative side of using AMO is that your users won't get a localized install experience of Firefox, including the profile migration dialogs. The in-product webpages will come up in one of the official languages of mozilla.com, bookmarks and search engines will be taken from the build that your users installed originally. If your users decide to upgrade to the next major version, your language packs will stop working, and get disabled like other incompatible Add-ons, until you uploaded a compatible version on AMO again. We are working on [link to any blog posts? or maybe status pages with notes about this] improving this process specifically for Language Packs to achieve our objective of a good user experience overall. If you're working on a dialect or a minority language, the disadvantages of language packs are not that bad [WHY?], but for languages spoken by people without a second language supported by the Mozilla community (thus far), getting Firefox out there requires more work. | The negative side of using AMO is that your users won't get a localized install experience of Firefox, including the profile migration dialogs. The in-product webpages will come up in one of the official languages of mozilla.com, bookmarks and search engines will be taken from the build that your users installed originally. If your users decide to upgrade to the next major version, your language packs will stop working, and get disabled like other incompatible Add-ons, until you uploaded a compatible version on AMO again. We are working on [link to any blog posts? or maybe status pages with notes about this] improving this process specifically for Language Packs to achieve our objective of a good user experience overall. If you're working on a dialect or a minority language, the disadvantages of language packs are not that bad [WHY?], but for languages spoken by people without a second language supported by the Mozilla community (thus far), getting Firefox out there requires more work. | ||