- 1 Intro
- 2 Language-specific Mozilla style
- 2.1 Style
- 2.2 Terminology
- 2.3 Units and Grammar
- 2.3.1 Units and Unit Conversion
- 2.3.2 Spelling And Grammar Checks
- 2.3.3 Word Forms
- 3 General Mozilla l10n style
Style guides define the standard against which we determine a translation's quality. They contain rules that are both defined by Mozilla and by Mozilla's localization communities on how to best translate text in Mozilla products, websites, and other projects. Style guides are used to both translate and evaluate a translation's quality. By following these rules, a translator has a better chance of producing a high quality translation that represents Mozilla values and culture. Some examples of international style guides created by other organizations are:
This style guide is broken up into two main parts: the first contains rules that are language-specific and must be defined by each Mozilla l10n community (covering language-specific style, terminology, and units); the second contains general rules that Mozilla has defined for translators of all languages that can help you translate well (covering principles of accuracy and fluency). Please adapt part one of this style guide to your l10n community's rules for style, terminology, and units. Wherever possible, refer to existing national standards for units, spelling, and grammar in your community's adaptation of the first part of this style guide.
Language-specific Mozilla style
Formality and Tone
We currently use formal tone on Firefox Desktop and informal tone on Firefox for Android and web content. This will change in a recent future, so please check later.
If it's possible, begin with the verb leaving out "usted" or "vos". For example "haga clic aquí" instead of "usted haga clic aquí"
Handling cultural references, idioms, and slang
Cultural references, idioms, and slang require a full understanding of these references between the cultures of your source and target languages. An example of a cultural reference in English would be the phrase, "kick-off meeting." This is a reference that uses an American football term. It means a meeting to begin a project. To translate it, you can follow one of two approaches:
- Find an equivalent reference phrase in your language.
- Remove the cultural reference and translate the core meaning (e.g., "a commencement meeting")
If you can't find an equivalent, then you may remove the reference.
Even in the informal products, you shouldn't use argentinian slang.
Finally, adherence to Mozilla and third-party branding and style guides should be respected throughout a localization project. More information on Mozilla-specific branding rules can be found here: https://www.mozilla.org/en-US/styleguide/identity/firefox/branding/. For example, some brand names should never be translated, such as "Firefox". For other brands that do not have any branding guidelines, there would be a debate for new ones to decide whether to translate them, but the preference is to leave them untranslated. Be extra careful to check on branding rules before deciding to translate a name or not (whether for Mozilla or for a third-party).
Tips on translating difficult concepts
Translating terms representing difficult concepts is a tricky task. Here are some ideas to help you translate terms that do not have equivalents in your language:
- Understand the meaning of the term in English. Definitions of a few key terms http://techterms.com/category/internet
- Know your product and understand the function of the feature.
- Consider similar ideas for those functions in your culture.
- Associate a culturally specific image with the meaning and function of the term.
- Ask to another member of the team
Developing new term bases
If you find a term that was never translated, please keep in mind the following.
- Avoid overly borrowing English expressions, only use them when it's a common use and there's no word in our language (e.g. You should use the word "clic" instead of "click")
- Referencing another language from the same language family may inspire you to come up with your own terms
Units and Grammar
The translation should strive to achieve proper unit conversions for currency, measurements, etc. for the target audience.
Units and Unit Conversion
The date formats for weeks and months are expressed in the following form:
- Fully spelled out
- The order of Year, Month and Day is day, month, year.
Reference material can be find here: https://en.wikipedia.org/wiki/Date_format_by_country
The first day of the week is Sunday No other regional calendar is observed.
Time is expressed in hours, minutes and seconds. 24 hour format.
Numerals and percentages are expressed in:
- Example: 1,23 (decimal separator) or 1.000 (thousand separator) using comma and period.
The most used currency and symbols used in our country/language are argentine pesos (ARS) and US dollars (USD).
We use the metric system for measuring weight, distance, etc., except for some devices's displays where size is expressed in inches.
The order of family name and given name in our language is given name and family name.
Spelling And Grammar Checks
Verbs that indicate action should be used in infinitive. e.g. "Abrir nueva ventana"
Verbs that indicate what happened must respect the original meaning, like "Firefox no abrió una ventana emergente"
Acronyms should be kept if it's the regular use in Argentina, like CD, DVD or MB. If there's an equivalent in spanish, you should use it.
You must respect the punctuation from the original sentence. If it ends with a period, you must include it. If it doesn't, don't put a period at the end.
Hyphens and compounds
Compounds (https://en.wikipedia.org/wiki/Compound_%28linguistics%29) don't have hyphens or spaces between the parts. For example "examigo" instead of "ex-amigo" or "ex amigo".
Our language has a standard use for quotation marks, parenthesis, and brackets.
Our language requires the use of white spaces after a comma and around sentences and paragraphs.
User Interface Elements
- Titles : Should be brief and precise. Localizers can assume that source content reaches 2/3 of the total available line space. This allows localization text to expand and not be truncated or resolved through ellipsis. Title on the final page (meaning no more click through) should allow enough room to display full text.
- Buttons: Capitalize the first letter of the first word and the first letter of any proper nouns. Limit to one or two words. Use verbs that precisely describe the button's action. For example, "Cancelar", "Borrar historial", "Agregar correo electrónico", "Seleccionar todo", etc.
- Value Selector Lists: Capitalize the first letter of the first word and the first letter of any proper nouns. Limit to one or two words.
- Articles: Avoid them where possible. Articles (such as the word "the" in English) should be avoided wherever possible. User interface elements have limited space available for text. Avoiding articles will help ensure that your translations will be accommodated within the user interface.
- Ellipsis: Ellipsis are often inserted automatically in the UI where strings are truncated. Ellipsis should only be used at high level of UI pages, but not be on the final page (after a series of click-through) where detailed instruction is given. Ellipsis should not be used as a way to solve truncation issue. Focus on making the UI short and precise. The sequence of the sentence structure in another language may not translate well, when a sentence is half finished as such. It's preferable to use the ellipsis character (…) instead of three dots.
General Mozilla l10n style
When it comes to translation, meaning is everything. A translator needs to understand the source text's meaning exactly. You then find its most closely linked equivalent in your own language, without adding or subtracting meaning in your translation. Finding meaning-based equivalents between languages can be difficult. To help concentrate your thoughts, ask yourself questions like:
- What does this word/sentence/string mean in English?
- What is the message the author is trying to send?
- How would I express that meaning in my own language?
Sometimes translation memory and machine translation tools can offer bad suggestions for a translation. If you use either as part of your translation workflow, make sure to correct the suggestions before submitting them. Avoid literal translation at all costs. Watch out for words that might sound or look the same between English and your language, but have a different meaning.
On technical documents, take a look to some words that had a standard localization. If you are unsure, you could ask on the localization mailing list.
Should not be translated
Access keys allow a computer to immediately jump to a particular part in a web page by combining keystrokes. They can be adapted to suit your language by selecting a single character to be used in the combined keystroke. Access keys have their own lines within .dtd and .properties files and are identified by being named ".accesskey" in the line.
Variables should never be translated. You can recognize a variable within a string by its beginning with a specific character (e.g., $, #, %, etc.) followed by a combination of words without spacing. For example, $BrandShortName and %S are variables. You can move a variable around within a string, if the translation of the string requires it.
Brands, copyright, and trademark
Brand names, as well as copyright and trademarks should never be translated, nor transliterated into a non-Latin based script. See the Mozilla branding guide for more details.
Translating culture-specific references
At times there will be English content included in Mozilla products or web projects (e.g., marketing campaigns) that makes references to American culture and concepts. When translating these, it is best to find an equivalent cultural reference within your own culture that accurately conveys the meaning of the English reference.
For example, an US citizen might say, "Good job, home run!" A home run is a baseball reference for a successful outcome. An appropriate translation would be an equivalent metaphor within your culture. Using soccer as an example, you might translate "Good job, home run!" into "Good job, nice goal!" in your language.
Also, there are specific Mozilla related concepts and localization, based on projects names and cultures. A person that participate in the organization is known like: "Mozillian", and these concepts had their own localized version. In this case "Mozillian" is translated liked "Mozillero".
Mozilla events names are not localized. E.g: "Mozilla Summit" or "Mozilla All Hands" are events names that we maintained in their original form.
Mozilla projects will often contain legal content in the form of user agreements, privacy statements, etc. When reviewing the translation of legal content, Mozilla localizers should do so according to the criteria concerning accuracy, fluency, style, and terminology found within this style guide and according to Mozilla culture and values.
To produce a fluent translation, not only should the translation follow the language's standard grammar, punctuation, and spelling rules, but it should avoid being ambiguous, incoherent, or inconsistent, and unintelligible.
To avoid ambiguity, the translator must thoroughly understand the meaning behind the source text, including any references that text might include. For example, if the English source text uses the word, "it", the translator must know what "it" is to avoid an ambiguous translation. Clearly understanding the source text will also allow a translator to make the source text's logical connections in their own translation. This helps to keep the translation coherent.
Inconsistency can pop up in many forms. A translator must be consistent in their use of abbreviations, references, and links within each localization project. They must also be consistent with Mozilla and the localization communities' style guides and approved terminology. Abbreviations, like terminology, should come from either a standard reference (like a dictionary of abbreviations) or should follow your language's rules for creating abbreviations. Once used, the abbreviation must remain consistent every place that it is used in the translation. Cross-references (or links) must also be consistently used within a translation. If a text contains a hyperlink URL to a support article in English, the translation should also contain a hyperlink to a translation of that support article (if available) or the English version. Links should not redirect to other pages nor should they be broken and unusable.
Finally, there are times that a translation simply doesn't make sense. It's hard to put your finger on what exactly is wrong with it, but you know it is unintelligible and not fluent. While this is uncommon, it's important to report these unintelligible translations and offer suggestions to correct them.