Style Guides

This repository is used to store localization style guides for Mozilla communities. All style guides and related documents are listed in the menu on the left of the page.

Updating the documentation

We use a GitHub repository to store all documents. Simply open a pull request adding the new file or updating an existing document. Make sure to follow these style guidelines, and note that all pull requests need to be reviewed before merging. The instructions for creating new community style guides are part of the guidelines for community style guides.

If you want content to appear on GitBook, it needs to be listed in docs/SUMMARY.md.

Guidelines for creating community style guides

This document provides step-by-step instructions for creating a community style guide. Community style guides are to be used in coordination with the Mozilla general localization style guide but provide additional information that is vital to producing a high-quality translation in the community locale.

For creating new style guides, we have prepared a template you can use. Each heading in the template represents a common style topic in localization. Each topic features one or more questions that pertain to the information of the topic. Below each question is a description of how to answer the question and some examples of relevant information.

Note: All style guides use Markdown, which you may know from GitHub already. If not, Mastering Markdown or Basic writing and formatting syntax will give you a good introduction.

How to use these guidelines

1. Create a folder for your locale in the /docs folder.
2. Copy the file with the style guide template to your locale folder.
3. Fill out each section of the template, using the questions and directions from the guidelines below. Refer to the example style guide as necessary.
4. Submit a pull request to the repository administrators.
5. Request a review of your style guide from another member of your community (if there are no other members of your community, include a note in your pull request).

If your community already has a style guide, you can follow these steps, using your style guide as a resource for relevant information, or you can use these guidelines to review and update your style guide.

The language you use in your style guide is up to your community. It is recommended that you use your language or English (or your source language if you don’t translate from English).

As you follow these steps, only include information that is relevant to your locale. If you are using the style guide template, remove sections of the template that do not apply to your language or locale and remove the included template comments as you complete sections.

Once you have updated or create your community style guide, submit a pull request to the repository managers.

Style guide Language (ab-CD)

• Formality and tone
• Natural expression
  • Cultural references, idioms, and slang
• Units and unit conversion
  • Date format
  • Calendar view
  • Time format
  • Numerals
  • Currency
  • Units of measurement
  • Address and postal code format
  • Telephone number format
• Grammar
  • Spelling and grammar checks
  • Punctuation
  • Whitespace
• Copy rules

Insert your locale name into the line below and leave it in your style guide unless it does not apply to your locale. You may translate it if your style guide is in your language

This style guide provides instruction for translating to the [Your locale name] locale. This style guide is to be used in coordination with the General Mozilla L10n Style Guide.

Include other relevant introductory information here, such as a community webpage or contact information.

Formality and tone

Who is the target user for this project and what is their background?

Describe briefly the users from your locale. If the type of user from one project to another will vary, indicate so here.

How would a target user for this project expect to interact with this project?

Describe the type of interaction users from your locale expect. Interactions could range from authoritative and formal to friendly and casual. Indicate what kind of tone is preferred in your locale.

Describe the features that create the right tone. For example, Spanish has multiple forms of the second person pronoun you. Generally, tu is considered informal and personal and usted is considered formal and impersonal. Mozilla’s Photon guidelines prefer an informal and personal interaction; however, if the culture of your locale prefers a formal interaction, that should be declared in your community style guide.

Is formal language or informal language appropriate for all of your language’s Mozilla l10n projects, or only some of them? Which ones?

If the tone varies from project to project, indicate what tone is best for which projects.

Natural expression

What kind of expression sounds natural in your locale?

Describe the features of a natural sounding localization.

Does your locale allow for many borrowed words and phrases or few?

List any important specific cases or include a link to any relevant resources. For example, the Spanish phrase, En ocho días could be translated as in eight days. However, a natural expression in English would be in seven days or even in a week. All three are correct translations, but the last two are more natural in English.

Cultural references, idioms, and slang

How are cultural references, idioms, and slang handled in your locale?

Define a policy for handling these cultural references, idioms, and slang that you can make standard across all projects.

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:

1. Find an equivalent reference phrase in your language.
2. Remove the cultural reference and translate the core meaning (e.g., a commencement meeting)

Are there resources for cultural references, idioms, and slang in your language?

List resources you can use to find cultural equivalents (e.g., a slang dictionary in your language).

Units and unit conversion

Does your locale use the metric system or the imperial system?

State which measurement system is used in your locale for weight, distance, etc. State any other measurement system information or units of measurement that are relevant to your locale.

Date format

How are the date formats for weeks and months expressed?

Declare whether dates are fully spelled out, abbreviated, or represented in another way and the order of year, month and day. This can be represented with a table. Erase the blockquote markers around the example template or show the format with your own example.

Name	Format	Example
Short	mm/dd/yy	12/31/99
Abbreviated	mmm dd	Dec 31
Long	Month Date, Year	December 31, 1999

Calendar view

Which date is considered the first day of the week, Sunday or Monday?

Is Lunar calendar observed? Other regional calendar observed?

Time format

How is time expressed in your language?

State how time is expressed including 0-24 hr expression, hour, minute and second if relevant.

Numerals

How are numerals and percentages expressed in your language?

Declare what the separators are for your number system and any other relevant information. This can be represented with a table. Erase the blockquote markers around the example template or show the format with your own example.

Separator	Character Name	Symbol	Example
Decimal	Period	.	1.23
Thousands	Comma	,	1,234
Percentage	Percent sign	%	99.95%

Currency

What currency and symbols are used in your country/language?

State what currency symbols are used in your locale. If your language covers different countries or currencies or common currency symbols vary depending on the project-by-project basis, declare the different types and uses.

Units of measurement

Do you use the imperial, metric or nautical system for measuring weight, distance, etc.?

Address and postal code format

What is the address format in your language?

Show the postal address format for your locale. Erase the blockquote markers around one of the examples or show the format with your own example.

Example: Most Asian countries start from big to small:

[Country]
[postal code][state/province][city][district]
[street number and name][building and suite numbers]
[addressee]

Countries of European languages start from small to big:

[addressee]
[street number and name][building and suite numbers]
[district][city][state/province][postal code]
[Country]

Telephone number format

How are telephone numbers expressed in your language?

Show the telephone number format. Does the format change for mobile and landline numbers? Adapt the example template or show the format with your own examples.

(###) ###-####

Grammar

Spelling and grammar checks

Does your language have standard spelling or grammar checks?

List and explain any spelling or grammar references for your language and how regularly they should be used.

Punctuation

Do you use different punctuation rules in your Mozilla localization than what your language standard defines?

Describe any variation in punctuation for Mozilla projects from language standards. If punctuation varies from project to project, list the projects that use variant punctuation.

Whitespace

Does your language require the use of white space around words, sentences, paragraphs, etc.?

Describe the relevant whitespace rules in your language as they pertain to Mozilla localization. If whitespace varies from project to project or depending on the interface element, describe how.

Copy rules

Please leave the following line in your style guide unless it does not apply to your locale. You may translate it if your style guide is in your language

Read about copy rules styles in the General Mozilla L10n Style Guide.

Is there an international/national standard for capitalization in your language?

Indicate whether your language uses title case, sentence case, all caps, or some other capitalization structure. If the style changes for different textual elements such as titles of movies, books, brand names, or userface elements (Save, File, etc.).

Is the capitalization standard appropriate for all of your language's Mozilla l10n projects or only some of them? Which ones?

If copy rules in your language change from project to project, list the copy rules for each project.

Is the capitalization standard appropriate for all user interface elements in your language or only some of them? Which ones?

Are there other typographical conventions regarding quotes, quotation marks, apostrophes, use of bold or italic text, all caps text, etc.

Example Style Guide English, USA (en-US)

• Formality and tone
• Natural expression
  • Cultural references, idioms, and slang
• Units and unit conversion
  • Date format
  • Calendar view
  • Time format
  • Numerals
  • Currency
  • Units of measurement
  • Address and postal code format
  • Telephone number format
• Copy rules
  • Firefox for desktop
  • Firefox for Android
  • Firefox for iOS and Focus

This style guide provides instruction for translating to the American English locale. This style guide is to be used in coordination with the General Mozilla L10n Style Guide.

Formality and tone

In English, the tone of Mozilla’s language should be adaptable to anyone. From new users to seasoned Mozillians, the tone should be approachable, welcoming, and inclusive.

Mozilla is fun and should delight the user in expected and unexpected ways. The level of formality should express a sense of familiarity and friendliness while maintaining a voice of authenticity.

In general, use the second person (you) to address the user in Firefox products. Firefox is a user agent, and this point of view reinforces the message that "Firefox works for you."

Avoid using the first person (my, I) as it can create confusion about who is being addressed.

In some projects (like Desktop, Android, iOS, Focus), the language will be direct as it belongs to a software string. This language should be maintained as direct, yet respectful, and remain casual as with all other projects. Casual language should never be used at the expense of sounding disrespectful, regardless of the project.

Natural expression

Translations should sound as natural as possible. Borrowed words should never be used (with the exception of branded names).

Cultural references, idioms, and slang

When dealing with cultural references, idioms, and slang in English, references to American pop culture (music, movies), sports (basketball, baseball, football), sayings, and some proverbs will be generally recognized. If a cultural reference is difficult to express in English, use the meaning to find a good equivalent. Refer to sources and databases of common expressions to help find an adequate equivalent.

• List of Common Proverbs
• List of Common Idioms

Units and unit conversion

Date format

It is acceptable to use any of the date formats; however, always coordinate the translated date format with the source text unless the specifications for a project indicate otherwise.

Calendar view

In the United States, the 12-month Gregorian calendar is used with the week starting on Monday.

Time format

Generally, a 12-hour clock is used in the United States. 24-hour clocks are used in the military and it is possible that 24-hour time could be used to make reference or allusion to military.

Numerals

Currency

The currency of the United States is the dollar (USD). The monetary symbols are $ and rarely ¢.

Units of measurement

The imperial system is used for measurement in the United States.

Address and postal code format

[addressee]
[street number and name][building and suite numbers]
[district][city][state/province][postal code]
[Country]

Mozilla
331 East Evelyn Ave.
Mountain View, CA 94041
USA

Telephone number format

Area codes are surrounded by parentheses and separated by a space. The Phone number is separated by a dash.

(###) ###-####

Copy rules

Read about copy rules styles in the General Mozilla L10n Style Guide.

Firefox for desktop

Use title case for labels for items in the menu, navigation and section headings, page titles, and buttons.

Use sentence case for headlines, which are the more conversational titles and subtitles that appear in instructional text screens, tours and form pages, and text links without terminal punctuation unless the phrase is a question or exclamation or if the link is embedded in running text.

Note, include the terminal punctuation in hyperlink if the entire phrase is linked, and do not include the terminal punctuation in the hyperlink if the link is within running text.

Firefox for Android

Use sentence case in almost all instances – for screen titles, navigation, labels – except for buttons.

Use all caps for all buttons that contain text.

Firefox for iOS and Focus

Use title case for screen titles, navigation and section headings, labels, and buttons.

Use sentence case for headlines, which are the more conversational titles and subtitles that appear in instructional text screens, tours and form pages.

Firefox localization copy guide

This document is intended to facilitate the creation and localization of copy, and to support optimal preparation and consistency. This is a living document and it reflects our current state. As our brand expression continues to evolve, we’ll make updates to this doc.

Why is this guide important for the localization of Firefox marketing copy?

This guide is intended to help you better understand Firefox as a brand to get a better sense of how to approach translating in your language. In addition, we’ll share fixed, company-specific word choices and spelling to facilitate the localization process.

Our copy should not be translated literally one to one, but should reflect our brand personality and tone and be optimized for the appropriate cultural and linguistic perspective. The emotional and figurative intention of the source text should be adapted for the target language.

About Firefox — Who we are

Firefox is more than just the browser. Firefox is a challenger brand that challenges the status quo and advocates for users’ online rights.

In everything we do, we put the rights and needs of users first. And as a tech company, we always put people before profit.

Firefox as a brand combines the Firefox ethos and our related products.

(Mozilla is the not-for-profit organization behind Firefox.)

Brand promise:

Firefox fights for you

What are we fighting for:

Firefox fights for our users by creating products that give people control and agency over their online lives.

Products:

• Firefox Quantum (Desktop browser)
• Firefox Mobile (For iOS and Android)
• Firefox Monitor
• Pocket
• Mozilla VPN
• Firefox Private Network (FPN)
• Firefox Relay

Personality and tonality

Who are we talking to?

We describe our target audience as Conscious Choosers. This refers to people who make or want to make conscious decisions, online and offline.

Conscious Choosers:

• Develop preferences and make consumer choices carefully and consciously
• Strive to reconcile their actions with their values and ideals
• Are demanding customers
• Often do their own research to fully understand all options

Within Conscious Choosers there are two groups that we try to speak to specifically. Caring Confidentials and Adventurous Amplifiers.

Caring Confidentials:

• Most likely to already be Firefox users
• Prioritize privacy, and are willing to spend money to ensure their digital safety
• Believe that the internet has a responsibility to protect its citizens

Adventurous Amplifiers:

• Trend followers and trend setters
• Want their friends and followers to witness the good choices they are making
• Strive to influence their community to make thoughtful choices as well

Our Brand Attributes and the Firefox Brand Personality

The Firefox Brand Personality is defined by the interaction of these attributes. Depending on the context, an attribute may be more prominent or less prominent.

Tone

Our tone of voice and language choices are:

Glossary of term / Recurring terms (WORK IN PROGRESS)

In case of uncertainties, the transvision search can also be consulted. However, as the search often shows older versions of translations in the result list (often with the formal address), this tool serves as a guide.

Mozilla general localization style guide

• Fluency
• Meaning-based translation
  • Translating culture-specific references
  • Units and measurement
• Terminology
  • Abbreviations and acronyms
• Text that should not be translated
  • Shortcuts and accesskeys
  • Variables
    • Cross-references and links
  • Brands, copyright, and trademark
    • Use in local languages with non-Latin script / permissible transcriptions
    • Use in local languages with Latin script
    • Translations of trademarks
    • Declensions
• Copy rules
  • Title Case
  • Sentence Case
  • All Caps
  • User interface elements

This style guide provides the basic guidelines for translating Mozilla products. This guide should be used in coordination with a locale-specific style guide for your language.

Fluency

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, inconsistent or 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.

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.

Meaning-based translation

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.

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 American 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.

Units and measurement

The translation should strive to achieve proper unit conversions for currency, measurements, etc. for the target audience. Source strings will use the imperial system (e.g., miles, pounds, feet, gallons, etc.). Target translations should convert imperial metrics to their measurement system when the measurement is provided as a number. If the measurement is provided as a variable, use the translation for the imperial system unit.

Terminology

You should be consistent in the use of terminology in your language. These term bases could be developed and approved by the community, or leveraged from another party that adhere to national, international or local standards for software and internet terminology. Avoid inconsistent use of terminology within the project, within term base, or across all of your projects and using terminology from another subject matter (e.g., don’t use medical terminology in Firefox).

Here are a few things to keep in mind when managing your team’s terminology:

• Avoid overly borrowing English expressions.
• Referencing another language from the same language family may inspire you to come up with your own terms.
• Consider the product target audience (age, level of literacy, education, social and economic status).
• Will you use loan words from another language or coin new terms in your language to maintain language purity? Is there government requirement or policy to encourage creating new terms for new concepts, or will loan words be sufficient to reach broader masses and expedite new technology adoption?
• If there are two acceptable scripts commonly used by the general public, what is the commonly used script on the web or government sites? What is the script used by major web technology companies?

Abbreviations and acronyms

Abbreviations and acronyms, should come from either a standard reference (like a dictionary of abbreviations) or should follow your language’s rules for creating abbreviations and acronyms. Once used, abbreviations and acronyms must remain consistent every place that it is used in the translation.

Text that should not be translated

Shortcuts and accesskeys

In Firefox and other software it’s possible to use keyboard shortcuts to invoke a specific command. For example, to open a file in Firefox you can press the combination of keys CTRL+O (Cmd+O on Mac). The accelerator key depends on the operative system, but the letter itself is normally localizable. This is what is called a shortcut, or commandkey. For example, the Open File… menu item is stored as

<!ENTITY openFileCmd.label "Open File…">
<!ENTITY openFileCmd.accesskey "O">
<!ENTITY openFileCmd.commandkey "o">

The commandkey is stored in openFileCmd.commandkey (sometimes the string has .key in the identifier). Normally you should not localize this key, since shortcuts are often common across the entire operative system (e.g. CTRL+S to Save) or similar products (CTRL+T to open a new tab in most browsers). But it needs to be localized if the letter is not available in your keyboard layout. For example, in Italian the character [ can be accessed through ALT+è, a command key [ would not work.

In the code fragment above you see also an accesskey defined for Open File…. Accesskeys are used to access a UI element from the keyboard. Example: if File menu has an accesskey F, and the Open file… menu has O, you can press ALT+F to access the menu, and then O to open a file.

If the label is File, and the accesskey is F, it will be displayed as File on Windows and Linux, with an underscored F. If the accesskey was O, so a character not available in the original label, it will be displayed underlined between parenthesis: File (O).

One important thing to determine is if, for your locale, it makes sense to have localized accesskeys: for example, if most users will use a keyboard with a different layout (English), it might make sense to keep the English original accesskey instead of using a letter available in your localization.

Accesskeys, like commandkeys, have their own lines within .dtd and .properties files and are usually identified by .accesskey in the string ID.

Variables

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.

Cross-references and links

Cross-references (or links) must 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.

Brands, copyright, and trademark

Trademarks present a special case for localization as they have legal as well as semantic significance. To ensure that localization does not undermine Mozilla’s trademarks rights, please follow these rules when translating content that includes trademarks.

This page has a list of Mozilla trademarks.

Use in local languages with non-Latin script / permissible transcriptions

When your local language is not written in the Latin alphabet and you use a Mozilla trademark in a headline, a prominent position, or for the first time on a site, you should always use it in its original form in Latin script (e.g. Mozilla, Firefox, Thunderbird). Mozilla trademarks should therefore not be altered in prominent UI elements. For example, do not alter “Firefox” in the first-run menus, or for the first use of the term in landing pages and legal notices.

If you use the trademarks in a referential context after that, within continuous text, you may use a transcribed local language version. If a transcribed local version is used, each community must take care to select a single version and use it consistently. This should be in the form that is the most used and accepted expression in digital/print media.

Correct example:

Finally released: the Firefox Quantum Update! In November 2017, Mozilla has released the latest version of its Firefox software. […]

Наконец выпущен: обновление квантового Firefox Quantum! В ноябре 2017 года Mozilla выпустила последнюю версию своего программного обеспечения для Файрфокс. […]

Incorrect example:

Finally released: the Firefox Quantum Update! In November 2017, Mozilla has released the latest version of its Firefox software. […]

Наконец выпущен: обновление квантового Файрфокс квантум! В ноябре 2017 года Моцилла выпустила последнюю версию своего программного обеспечения для Файрфокс. […]

Use in local languages with Latin script

When your local language is written in the Latin alphabet, you should always use Mozilla’s trademarks in their original Latin script form. This also applies if the respective terms should be pronounced differently in your local language. You should therefore not modify the original Mozilla trademarks in order to reflect or facilitate local pronunciation.

Correct example:

In November 2017, Mozilla has released the latest version of its Firefox software. […]

W listopadzie 2017 roku Mozilla wydała najnowszą wersję swojego oprogramowania Firefox. […]

Incorrect example:

In November 2017, Mozilla has released the latest version of its Firefox software. […]

W listopadzie 2017 roku Mozilla wydała najnowszą wersję swojego oprogramowania Firefoks, […]

Translations of trademarks

Always use Mozilla’s trademarks in their original wording, even if you are transcribing them into your local non-Latin alphabet (per the guidance under point 1 above). For example, do not translate Firefox into another language by using words that have the meaning of “fire” and “fox” in that language.[1]

If you want to explain how a Mozilla trademark is pronounced in your local language or what it means if translated literally, you may do so in a referential context only. When doing so, you should also state expressly that you want to explain the meaning or pronunciation of the term.

Correct example:

The newest version of the Mozilla Firefox software – which literally means “fire fox” – outpaces its opponents and lives up to its name. […]

Die neueste Version der Firefox Software – was wörtlich übersetzt “Feuerfuchs” bedeutet – überholt all ihre Konkurrenten und macht ihrem Namen alle Ehre. […]

Incorrect example:

The newest version of Mozilla’s Firefox software outpaces its opponents and lives up to its name.

Die neueste Version von Mozillas Feuerfuchs Software überholt all ihre Konkurrenten und macht ihrem Namen alle Ehre.

[1] The only exception to this rule is the Chinese characters for “Fire” and “Fox” together. Mozilla has a registered trademark on these characters (China Reg. No. 16199671A).

Declensions

As noted above, when you use a Mozilla trademark in a headline, a prominent page position or UI element (such as first-run application menus or the first use of the term in landing pages and legal notices), or for the first time on a site, you should always use it in its original, unaltered form.

If your language requires declension of proper nouns and adjectives, try to limit their use to the following cases:

• Grammatical unintelligibility requirements.
• The contextual meaning of the proper noun requires the declension.
• The UI cannot accommodate a large enough translation to avoid it.

In other cases, avoid using declension on trademarks.

Never use Mozilla trademarks as verbs and do not coin verbs out of Mozilla trademarks.

Copy rules

Title Case

Title case is a capitalization style that includes the following rules:

• Always capitalize the first and last word in the text element, regardless of part of speech or other rules below.
• For words in between the first and last, capitalize all nouns, verbs, adverbs and pronouns.
• Capitalize conjunctions of four or more letters, but also capitalize if.
• Capitalize prepositions for four or more letters.
• Do not capitalize articles, prepositions of three or fewer letters, and conjunctions of three or fewer letters (but not if).
• A note about hyphens: capitalize the second word in a hyphenated compound if it would normally be capitalized as a single word according to title case rules. So, capitalize the S in Quick-Search Options, lowercase the o in Add-on Choices.

Example: All Your Activity.

Sentence Case

Sentence case is a capitalization style where the first word of the text element is capitalized as well as any words that are normally capitalized.

Example: Sign in to continue to Firefox Sync.

All Caps

All Caps is a style where every letter is capitalized.

Example: CANCEL.

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.
• Headlines: which are the more conversational titles and subtitles that appear in instructional text screens, tours and form pages
• Buttons: capitalize the first letter of each word. Limit to one or two words. Use verbs that precisely describe the button’s action. For example, Cancel, Clear History, Add Email, Select All, 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.

Style Guide Afrikaans (af)

Introduction

This style guide is intended for translators working on Mozilla projects. It provides in-depth information about the quality standards expected by Mozilla for the translation of all product components. All translators should read this guide before commencing any translation work.

This guide addresses general translation issues and specifies certain rules of style and usage specific to your language. It should be used as a guideline to avoid common typographic errors, and to maintain consistent terminology and writing style across a project’s components and indeed a product range. The guide should be used in conjunction with the current and previous product-specific glossaries, glossaries of other products of a product range, and the industry standard platform-specific glossaries, such as those provided by Mozilla.

This document may be updated or completed in the course of translation. Where no specific instruction or recommendation is specified, translators should use the phrasing and style that comply with industry standards.

General Style Considerations

Style guidelines

Follow these basic rules:

• Original American English text tends to be rather casual. For Afrikaans, use a neutral style, with the informal form of address.
• Try to avoid long, nested sentence constructions. If necessary, break up the original sentence and regroup it syntactically.
• Use wording that is brief and unambiguous.
• Use a consistent style throughout all product components and across a product range, to ensure that all Mozilla products can be linguistically identified as part of a group of products.

Style guidelines specific to Mozilla products

• Please refer to the reference documentation supplied by Mozilla and any Mozilla style guides and make a note of anything significant and specific that should be noted with respect to Mozilla.
• Please ensure to use a recently published dictionary (recommended source: Pharos 5-1 CD-ROM / Pharos Online list of technical dictionaries).
• Before returning any files, please be sure to run a recent Afrikaans spellchecker (in case of disagreements, the HAT spelling will be followed).

Reference terminology

The following terminology sources should be used as reference in the translation:

• Product-specific glossary, to ensure consistency across all product components.
• Previous version product-specific glossary, to ensure consistency between versions.
• Glossaries of other Mozilla products, to ensure cross-product consistency.
• Microsoft glossaries, to ensure adherence to some of the industry standards. The glossaries can be found at: http://www.microsoft.com/Language.

Terminology not found in the glossary or style guide

• Please make a log of any terms not found in the glossary or style guide that are used frequently in the materials. Return this log to Rubric so that the terms can be incorporated into the glossary. This increases consistency in large projects.

Abbreviations

General Abbreviations

• Avoid the use of non-standard abbreviations. Where no appropriate abbreviation exists, rather use the whole word.
• Where there are space restrictions in the UI, abbreviations can be used. These must be entered into the glossary with the full translation, and should be approved by the customer.
• This matter is dealt with in detail and is cross-referenced in AWS10 under 3.14, 3.20, 7.1, 7.2, 12.8–12.12, 14.5 and 14.9–14.12. These rules should be followed closely.
• The compounds below contain either an abbreviation or a numeral followed by a component name. The abbreviation or numeral is marked in red in the English example. The Afrikaans example below show how such constructions should be translated.

Note the difference between the styling of “5¼-duim-disket” and “35 mm-skyfies”, which results from the fact that "mm" is regarded a symbol and not an abbreviation. South Africa, and therefore Afrikaans, officially use the metric (SI) system, which requires as space between a figure and the accompanying symbol – see AWS10, 7.10–7.17.

Measurements and Numerals

In addition to common measurements such as km, m, cm, mm, etc., the following abbreviations are used in technical documentation:

Important: The old rule that all numerals up to 12 must be spelled out is no longer valid. Use your best judgment given the at hand, especially when a combination of numbers is involved.

Example: Twee 1-GB-hardeskywe.

Filename Extensions

• Filename extensions and graphic formats referenced by filename extensions such as BMP, GIF, HTML, PNG, TIFF must not be translated.

Acronyms

Acronyms are made up of the initial letters of several words that are represented by these letters. Some well-known examples are WYSIWYG (What You See Is What You Get), OLE (Object Linking and Embedding), or RAM (Random Access Memory).

If an acronymn has an official or commonly recognised translation in Afrikaans (e.g. if it is present in a general dictionary), use the Afrikaans acronymn. Otherwise, use the English acronymn. If the acronymn is followed in English by a full form, retain the acronymn in English and translate the full form into Afrikaans.

IMPORTANT: Do not translate an abbreviation or acronym that is a trademark, unless it is the official translation of that trademark.

Use recognised translations of acronyms where these exist, but avoid creating new, non-standard acronyms.

**Examples:**
Data Access Objects (DAO) = Datatoegangsvoorwerpe (DAO)
ActiveX data objects (ADO) = ActiveX-datavoorwerpe (ADO)

Articles

Product Names

Mozilla product names are used without definite or indefinite articles. Product names and non-translated feature names are considered proper nouns and are used without definite or indefinite articles in English.

Note that the product and feature names are regarded as proper nouns. When these form part of a compound noun in Afrikaans, the preferred style is to hyphenate and not to write the common-noun part of the compound separately, e.g. (+) Windows Mail-kieslys, (+) Internet Explorer-opsies. No hyphens should be inserted between parts of the product and feature names when that proper noun forms part of an Afrikaans compound noun, e.g. () Windows-Mail-kieslys, (-) Internet-Explorer-opsies. See in particular AWS10, rules 14.6 (including pp. 118 & 119) to 14.12.

By contrast, translated feature names are used with a definite or indefinite article as they are not treated as proper names.

Copyrights and Trademarks

Product names should not be translated unless the client requests it. |

Copyright protection is granted to any original work of authorship fixed in any tangible medium of expression from which it can be perceived, reproduced, or communicated.

Translation of Version Strings

• Please use the following guidelines when localizing version strings:
  • Version strings that contain copyright information should always be translated.
  • (Example: Kopiereg © 2005 xyz. Alle regte voorbehou.)
• In version strings containing feature names that are trademarked, the feature names that are trademarked should not be translated.

Gender-neutral Translation

In cases where a noun that denotes a male person or animal has a counterpart that denotes the female by means of a suffix, use the male form, unless the male form normally indicates to Afrikaans readers that female is excluded.

Instead of stressing gender differences or reinforcing stereotypical distinctions between men and women, use language that is as neutral as possible. The neutral approach also applies to the localization of scenarios, comparisons, examples, illustrations, and metaphors.

When assigning roles and functions to men and women (active vs. passive roles, leading vs. secondary roles, technical vs. non-technical professions, and so on), follow the English source text. Scenarios, pictures, metaphors, and comparisons should be based on areas and attributes common to both genders.

Instead of using phrases which mention the two genders separately, use a general term that includes both genders such as “mense”, “gebruikers” or “persone”.

Avoid writing sentences that refer to a single person whose gender is unknown. You can often avoid this situation by rewriting the sentence to make the subject plural. In cases where a reference to a single person is impossible to avoid, use “hy/sy”, “sy/haar” or “hom/haar”. The language in Mozilla products should, however, sound natural, as if part of a spoken conversation.

Use the following strategies to avoid the use of overtly gender-biased expressions:

Special Afrikaans notes:

1. For Mozilla translations, it is NOT acceptable in Afrikaans to use a plural pronoun if the antecedent is singular, e.g. “Die gebruiker moet hulle vergewis van die inhoud van die lisensiekontrak” is not acceptable, even though this is increasingly done in English. (The only exception to this rule may occur when the antecedent is nominally singular but notionally plural, e.g. some collective nouns.) Therefore, the use of a plural pronoun with a singular antecedent is not an acceptable way of avoiding gender-specific language.
2. Afrikaans uses the masculine pronoun (hy/sy/hom) to refer to non-human objects, and not the non-personal (neuter) pronoun dit, e.g.

• (+) Die rekenaar werk nie want sy hardeskyf is stukkend. (The PC doesn’t work because its hard disk is broken)
• (+) Die motor kan nie ry nie want hy het nie ’n battery nie.(The car won’t go because it doesn’t have a battery.)
• (+) Die hond het vir hom ’n skaduplekkie gesoek. (The dog found itself a patch of shade.)

The non-personal pronoun “dit” can be used, of course, but mostly as sentence or clause subject or object.

In cases where a noun that denotes a male person or animal has a counterpart that denotes the female by means of a suffix, use the male form, unless the male form normally indicates to Afrikaans readers that female is excluded, or restructure the text to avoid any overt mentioning of gender on the noun.

• A custom dictionary can only be used by the user who created it.
  • (+) ’n Pasgemaakte woordeboek kan slegs gebruik word deur die gebruiker wat dit geskep het.
• A custom dictionary can only be used by the person who created it.
  • (+) ’n Pasgemaakte woordeboek kan slegs gebruik word deur die persoon wat dit geskep het.
• All users who use this feature.
  • (+) Alle gebruikers wat hierdie stelsel gebruik.
• All who use this feature.
  • (+) Almal wat hierdie stelsel gebruik.
• Even if you are not a statistician, Microsoft Excel offers you...
  • (+) Selfs al is jy nie ’n statistiekkenner nie, kan Microsoft Excel jou help om ...
• Even if you understand little about statistics, Microsoft Excel offers you...
  • (+) Selfs al verstaan jy nie veel van statistiek nie, kan Microsoft Excel jou help om ...
• Some of the best snapshots could be made because the photographer...
  • (+) ’n Mens kry soms die beste foto’s omdat die fotograaf ...
• Some of the best snapshots could be made because the person who took the photo...
  • (+) ’n Mens kry soms die beste foto’s omdat die persoon wat die foto’s geneem het, ...
• If you have fun, your friends and relatives will be...
  • (?) As jy pret het, sal jou vriende en familie...
• If one is having fun, friends and relatives will be...
  • (+) As ’n mens iets geniet, sal vriende en familie.
• Create an appealing and secure shopping environment for your customers.
  • (+) Skep ’n aangename en veilige koopomgewing vir jou klante.
• Create an appealing and secure shopping environment for your clientele.
  • (?) Skep ’n aangename en veilige koopomgewing vir jou kliënte.

Genitive

The relative pronoun “who” is translated as “wat” [= ‘that, which’] irrespective of whether its antecedent is human or non-human, except when the relative pronoun is accompanied by a preposition or the particle “se” (the possessive particle), in which case “wie” [= ‘who, whose’] is used, e.g.

• (+) Die program wat gebruik word, is verouderd. (The program that is used is obsolete.)
• (+) Iemand wat die lisensievoorwaardes oortree, sal… (Someone who does not comply with …)
• (+) ’n Gebruiker wat sukkel, kan die hulplyn gebruik. (A user experiencing problems may use the help line.)
• (+) ’n Gebruiker wie se rekenaar te klein is, gaan sukkel. (A user whose PC is too small …)
• (+) Die mense na wie jy soek, is … (The people you’re looking for are …)

Localized term vs. English term

The most common language of terminology in the computer world is English. However, it is quite unnatural in Afrikaans to use English words in an Afrikaans sentence (except for product names and acronyms). Resist the temptation to borrow an English word as-is. Find out what the word means, and create a term that a reasonably intelligent Afrikaans reader will understand.

Gender

Many terms in circulation in the high tech industry have been adopted from English. They must follow Afrikaans grammar and syntax rules.

Inflections

The examples below show how English loanwords inflect for number in Afrikaans.

Verbs and Verb Forms

Do not use an English verb as loan word in Afrikaans.

Headings

Headings should convey as much information as possible about the ensuing text to help readers locate information quickly. If in English the heading begins with a gerund, use the nominalized verb (without article) whenever possible.

Capitalization

• In English headings, all nouns, pronouns, adjectives, verbs, adverbs, and subordinate conjunctions (such as “that,” “until,” and “which”) are capitalized. Please do not apply the same principle to Afrikaans headings. Instead, follow the normal Afrikaans capitalization rules. The same rule applies to software strings.

• Normal syntactical capitalization should be used in Afrikaans, bearing in mind that buttons, tags, etc. should be clearly identifiable as such “Klik op Hulp” or “Gaan na die Tuis-strook”. The use of capital letters is dealt with in Chapter 9 of AWS10. If a heading or label uses multiple words and is not in a different format, enclose it in double quotes in Afrikaans.

In Lists and Tables

Whenever possible, headings of lists and tables should consist of one or two words, preferably active nouns. They should be concise, even if the source uses a longer phrase.

In English, lists may be headed in two ways, namely (a) an introductory phrase that is completed syntactically by every item in the list and (b) an “independent” introductory phrase followed by syntactically independent items.

In English, the syntax of the items are typically not affected by the phrasing of the introductory phrase, if it is one sentence. However, in Afrikaans, the word order of the introductory phrase can affect the word order of the individual items. When translating the introductory phrase, try to translate it in such a way that the items can be translated as an independent phrases.

Either way, care should be taken to ensure that every individual item is not an incorrect syntactical completion of the heading and makes sense in terms of meaning (semantics) and subject matter. Note that the position of the (main) verb may require a structure that differs significantly from the English.

(In the examples below, “How to use” would require the infinitive form of the verb in Afrikaans, which requires the object to be placed before the main verb, for example “How to use a mouse” would become “Hoe om ’n muis te gebruik”, and therefore translating the heading as “Hoe om te gebruik” would result in incorrect syntax. The heading “First do this” may, depending on what follows, be translated as simply “Doen eers”, for instance in “Doen eers … die berekening”. The context will be the determining factor. The context would also determine whether a heading like “Walkthrough” represents a verb or a noun; in this case the verb would be “Loop deur” and the items should then follow on that verb correctly.)

Hyphenation and Compound formation

General Hyphenation Rules

In Afrikaans, hyphens are more common and more acceptable than in English. In fact, hyphens can be used in long compound nouns to make its meaning clearer. When faced with a highly complex compound, resolve it by clarifying the relationships among the various compound components. Ways of doing this include shifting the word order or using prepositions.

Examples:

The explanatory orientation on pp. 118–120, as well as rules 14.6–14.12 in AWS10 should be studied and followed closely. Note that while AWS10 allows various possibilities in compounds containing proper nouns (14.6–14.12) the hyphenated variant (i.e. proper noun + hyphen + lower-case common noun) is the preferred form for Windows 7.

This applies in particular to Mozilla product and component names that appear as the proper-noun element in compounds that are either proper nouns again, or common nouns (Examples below include Microsoft/Windows product names).

English Compounds

We do not automatically hyphenate purely English compounds. Use the following steps in handling US compounds:

• If the compound consists of no more than 3 components write it as one word in Afrikaans, unless there is serious risk of misunderstanding.
• If the compound is more complex, resolve it by:
  • inserting a hyphen at the appropriate point in the word (try to avoid using more than one hyphen in a single word, unless one of the hyphens is required and the other is optional).
  • adjusting the word order and applying the rules of Afrikaans syntax,
  • using prepositions,
  • reducing complexity by writing related components as one word.

Product Names

Product names must not be hyphenated. However, in order to offset the actual product name from the word that follows in a compound, the hyphen is placed right between the product name and the following term. Please note that this rule applies even if the word that follows is a US term.

Compounds with Acronyms, Abbreviations or Numerals

This matter is dealt with in detail and is cross-referenced in AWS10 under 3.14, 3.20, 7.1, 7.2, 12.8–12.12, 14.5 and 14.9–14.12. These rules should be followed closely.

The compounds below contain either an abbreviation or a numeral followed by a component name. The abbreviation or numeral is marked in red in the English example. The Afrikaans example below show how such constructions should be translated.

Note the difference between the styling of “5¼-duim-disket” and “35 mm-skyfies”, which results from the fact that "mm" is regarded a symbol and not an abbreviation. South Africa, and therefore Afrikaans, officially use the metric (SI) system, which requires as space between a figure and the accompanying symbol – see AWS10, 7.10–7.17.

Indexes

Capitalization, Prepositions and Articles

For first level entries (main index level), always capitalize the first letter of the first word. Write the remaining words according to existing Afrikaans capitalization rules.

Subentries: capitalize nouns, use lowercase for other entries.

In English headings, all nouns, pronouns, adjectives, verbs, adverbs, and subordinate conjunctions (such as “that,” “until,” and “which”) are capitalized. Please do not apply the same principle to Afrikaans headings. Instead, follow the normal Afrikaans capitalization rules. The same rule applies to software strings.

Normal syntactical capitalization should be used in Afrikaans, bearing in mind that buttons, tags, etc. should be clearly identifiable as such “Klik op Hulp” or “Gaan na die Tuis-strook”. The use of capital letters is dealt with in Chapter 9 of AWS10. If a heading or label uses multiple words and is not in a different format, enclose it in double quotes in Afrikaans.

All parts of a name use initial capitals. For use of capitals in certain surnames (often used as middle names) consisting of more than one element (mostly of French and Dutch origin), see rules 9.7 – 9.10 of AWS9.

Prepositional phrases in English need to be translated according to their context; anglicisms should be avoided. The table below contains frequently used verbs and the prepositions that follow them. Please use this table as a reference.

This is a particularly problematic area, because some verbs used transitively in English cannot be so used in Afrikaans, and then something needs to be added or changed in translation, for instance migrate cannot be used transitively in Afrikaans, and so a link verb like laat needs to be added: laat migreer (or a similar translational solution used). Also, Afrikaans phrasal verbs will change (be “split”) depending on the particular syntactical environment. This matter should be dealt with extremely carefully.

Generally speaking, Afrikaans uses only one definite article, namely “die”, and one indefinite article, namely “ ’n”. There is no grammatical gender. Most past-tense verbs are formed by the addition of “ge-” to the verb. A very typical Afrikaans word is “baie” [= ‘many; much; numerous’]. There is a strong presence of Romance languages in Afrikaans (as in Dutch and English), and many words found in for instance French or English will be recognisable in Afrikaans, albeit in a spelling-adapted form.

Prepositions

Translate English prepositions according to their context and not too literally.

Prepositional phrases in English need to be translated according to their context; anglicisms should be avoided. The table below contains frequently used verbs and the prepositions that follow them. Please use this table as a reference.

This is a particularly problematic area, because some verbs used transitively in English cannot be so used in Afrikaans, and then something needs to be added or changed in translation, for instance migrate cannot be used transitively in Afrikaans, and so a link verb like laat needs to be added: laat migreer (or a similar translational solution used). Also, Afrikaans phrasal verbs will change (be “split”) depending on the particular syntactical environment. This matter should be dealt with extremely carefully.

The examples below contain frequently occurring noun phrases that are preceded by a preposition. Please use this table as a reference.

Procedures and Syntax

In procedural text, which tells the user to perform certain actions in a certain number of steps, the order in which interface terms are to appear in the translation is usually top to bottom (for example, “menu,” “command,” “dialog box,” “dialog box controls”). This order reflects the sequence in which the action needs to be performed, and it should be maintained unless there are technical reasons preventing it.

This convention is less important in normal body text, which is sometimes written in a more personal tone and less formal style, thus allowing the translator to be more creative.

See also sections 4.5.5 and 4.6.2.2.

Descriptors

Use the descriptor (“menu,” “button,” “command,” and so on) only if the original text uses it or if it is needed for clarifying the position of a term in the interface.

Procedural Syntax

In procedural text, which tells the user to perform certain actions in a certain number of steps, the order in which interface terms are to appear in the translation is usually top to bottom (i.e. menu, command, dialog box, dialog box controls). Maintain this sequence unless there are technical reasons preventing it.

Example:

In the "Extras" menu, click "Settings" and then "Music files".

You may come across procedural instructions of the type "To do this and that, click on ...". In body text, you may rearrange such sentences to first mention the action the user needs to do and then the purpose.

Procedural Headings

Procedural headings are very important because they tell users exactly what they are going to do in the steps that follow. Headings should convey as much information as possible about the ensuing text to help readers locate information quickly. If in English the heading begins with a gerund, try to use a nominalized form in Afrikaans.

Status Bar Messages

Please make sure you adequately capture the meaning of messages when translating.

If you think a source status bar message is ambiguous, query it to make sure you provide the reader with the right information: if you cannot understand it, they are also not certain to. There is nothing more annoying than "help" that doesn't!

A status bar message is information about the active document, a selected command, or any active selected interface item. The messages are shown in the status bar at the bottom of the window when the user has chosen a menu, a command or any other item, or has started a function. Some status bar messages refer to actions being performed or already completed (for example in Microsoft Internet Explorer). Refer to

Figure 1. Example of a typical status bar and status bar message.

Messages reporting that a process is executing usually use a verb in the “-ing” form plus three dots after the text. In Afrikaans you should choose a verb tense and/or aspect that expresses the ongoing nature of the action.

Difficulties can arise if this convention is not kept in the US text and the status or progress message is not immediately recognizable as such (although sometimes the Resource ID will tell). The standard syntax should be applied to status bar messages wherever possible.

Examples:

Usage of "Select"

Usage of "Click"

Punctuation

Commas and Other Common Punctuation Marks

Please follow the following basic rules for the use of punctuation marks in Afrikaans. Make sure to include a space after commas, and after periods if it is followed by another sentence. Use one space between sentences.

There are a few important punctuation conventions that need to be observed:

1. The predicates of complex sentences are separated by a comma, whether or not they occur next to each other in the sentence. After the infinitive (om te + verb) as a noun clause no comma is needed.
2. A defining adjectival clause is terminated by a comma, unless two equivalent clauses are linked by “en” or “of”, or, of course, unless it is the final clause of the complex sentence.
3. A non-defining adjectival clause is preceded by a comma before the relative pronoun and is terminated by a comma.
4. A dash (en dash) between words should be preceded and followed by a single space.

Comma vs. Period in Numerals

English uses a period as decimal separator, Afrikaans usually uses a comma.

Example:

English:    5.25 cm
Afrikaans:     5,25 cm

English:  Letter Landscape 11 x 8.5 in
Afrikaans: Letter Querformat 11 x 8.5 in

English:    1,526
Afrikaans:    1 526

In bullet lists, instruction lists, captions and callouts:

• If your translation is longer than the US text, or if you split your translation into several independent sentences, use common sense and insert a period if it improves the Afrikaans style.

US English uses a period as the decimal separator, while many other languages use a comma. In Afrikaans a comma is used.

In paper sizes (the last example in the table below) the decimal separator and the abbreviation "in" for inches are kept, since the sizes are US norms and should be represented accordingly.

The “in” as abbreviation for “inch” is not acceptable in Afrikaans, and should be changed to “dm.” – note the full stop! – which has been the recognized abbreviation for decades. Before independence, South Africa as part of the British Empire used the imperial measurement system in which “inch = duim” and “in = dm.”.

For thousands, English uses a comma while many other languages use a period (at Mozilla we normally do not use a space for this purpose, but we use a period instead to avoid wrapping problems).

Note that neither a full stop nor a comma may be used for thousands, because both may be interpreted as a decimal separator. A space should be used for thousands and preferably a hard space to avoid wrapping problems.

Note that there should be NO SPACE between the currency symbol and the first digit!

Version Numbers

Version numbers always contain a period (Version 4.2, for example). Please note the following punctuation examples of “Version x.x”:

Examples:

Version numbers are usually also part of version strings, but technically they are not the same. Where possible in Afrikaans, leave out “weergawe” because it would in most cases require a hyphen to link it to the product name, which will only complicate matters.

Access Keys (also known as Hot Keys)

“Hot keys” are a combination of keys such as ALT+F or Ctrl+S that move the focus to a menu, command, or control, without using the mouse.

The following table lists special options for hot keys in US-English interfaces and describes whether each option is allowed in Afrikaans:

Typographic Conventions

Consistent use of typographic conventions in documentation helps users locate and interpret information easily. Generally speaking, the source format should be followed as closely as possible, i.e. terms with a particular formatting in the source should have the same formatting in the translation.

If menu, command, option, etc. names are highlighted by bold print in the source, use bold print for the corresponding translated terms. If menu, command, option, etc. names are put in quotes in the source, use quotes for the corresponding terms in the translation.

Note that in software strings, you must use two double quotes (""xxx"") to denote names within a string. If you only use a single double quotes ("xxx"), this will cause problems with the compilation, as strings are generally denoted by double quotes.

Wizard Names

Abbreviations: N = Noun, A = Adjective (incl. participle used as A), Nv = Verb used as Noun

Appendix

Guidelines for the Localization of Error Messages

The following guidelines do not apply to the translation of FirefoxOS because brevity is more important in FirefoxOS than using long, pleasant sounding idiomatic expressions.

Articles and Pronouns

Verbs

Negation

Style Guide Arabic (ar)

Introduction

This style guide is intended for translators working on Arabic Mozilla projects. It provides in-depth information about the quality standards expected by Mozilla for the translation of all product components. All translators should read this guide before commencing any translation work.

This guide addresses general translation issues and specifies certain rules of style and usage specific to your language. It should be used as a guideline to avoid common typographic errors, and to maintain consistent terminology and writing style across a project’s components and indeed a product range. The guide should be used in conjunction with the current and previous product-specific glossaries, glossaries of other products of a product range, and the industry standard platform-specific glossaries, such as those provided by Microsoft.

This document may be updated or completed in the course of translation. Where no specific instruction or recommendation is specified, translators should use the phrasing and style that comply with industry standards.

General Style Considerations

Style guidelines

Follow these basic rules:

• Original American English text tends to be rather casual. For Arabic language the general style should be clear, friendly and concise. Being friendly does not mean using overly colloquial language – it is crucial to consistently maintain a professional tone, but use contemporary, up-to-date style and common words. Use language that resembles conversation observed in everyday settings as opposed to the formal, technical language that is often used for technical and commercial content.
• Try to avoid long, nested sentence constructions. If necessary, break up the original sentence and regroup it syntactically.
• Use wording that is succinct, unambiguous, and free of jargon.
• Produce a translation that sounds as it if was originally written in your language, i.e. avoid following the original source sentence structure too closely.
• Always bear in mind who your target audience is (i.e. an experienced computer user, a beginner, or a combination of both groups).
• Use a consistent style throughout all product components and across a product range, to ensure that all Mozilla products can be linguistically identified as part of a group of products.

Style guidelines specific to Mozilla products

• Please refer to the reference documentation supplied by Mozilla and any Mozilla style guides and make a note of anything significant and specific that should be noted with respect to Mozilla.

Reference terminology

The following terminology sources should be used as reference in the translation:

• Product-specific glossary, to ensure consistency across all product components.
• Previous version product-specific glossary, if any, to ensure consistency between versions.
• Glossaries of other Mozilla products, to ensure cross-product consistency.
• Microsoft / Apple glossaries, to ensure adherence to the industry standards. It is your responsibility to make sure that you always have the latest Microsoft and Apple glossaries at your disposal. The glossaries can be found at: http://www.microsoft.com/Language and https://developer.apple.com/download/more/?=Glossaries

Terminology not found in the glossary or style guide

• Please make a log of any terms not found in the glossary or style guide that are used frequently in the materials. Return this log to Rubric so that the terms can be incorporated into the glossary. This increases consistency in large projects.

Abbreviations

General Abbreviations

• Avoid the use of non-standard abbreviations such as min. for minutes. Where no appropriate abbreviation exists, use the whole word.
• Note: KiArabic time is counted differently from the am/pm system used in Europe and the US. However, computer systems have not yet been designed that correctly localize time for the East African market. Therefore, computer users currently use the am/pm system when they are interacting with technological components.

Measurements and Numerals

• Be careful of the difference in use between periods and commas as decimal markers in different languages.

Numbers (includes currency, dates and times)

We use numbers in text, when referring to currency, and in time stamps and dates.

In offline files, use numerals for numbers greater than ten. Numbers one through ten should be written out in full.

On the UI and in series of numbers or measurements, use all numbers (even 1).

From 0 to 9999, digits should be together with no separator, while from 10 000 onwards a nonbreaking space should be used to set off groups of 3 digits.

• 10

• 100

• 1000

• 10 000

• 100 000

• 1 000 000

• Use a comma as decimal separator.

Currency

Use the numerical form and stick to the English source. If you need to mention currency or time alongside another type of number, spell out the other number to make the currency or time more prominent (ex: buy two deals and save $20 – nunua matoleo mawili na uokoe $ 20 ).

Note: Don't localize amounts from US Dollars to Ksh (or other currencies) yourself unless it is clearly an example that has been made up.

Time stamps and dates

Use the numerical form and write the numbers as compactly as possible. Use 12 hour clock.

• 5 minutes ago ( dakika 5 zilizopita)
• January 9 at 9:16pm ( Januari 9 saa 9: 16pm)

Filename Extensions

• Filename extensions and graphic formats referenced by filename extensions such as BMP, GIF, HTML, PNG, TIFF must not be translated.

Acronyms

Acronyms are made up of the initial letters of several words that are represented by these letters. Some well-known examples are WYSIWYG (What You See Is What You Get), OLE (Object Linking and Embedding), or RAM (Random Access Memory).

Use recognised translations of acronyms where these exist, but avoid creating new, non-standard acronyms.

Examples:

Data Access Objects (DAO)
ActiveX data objects (ADO)

In Arabic, many acronyms are standardized and remain untranslated. They are only followed by their full spelling in English if the acronym needs to be explained to KiArabic-speaking audiences. In other cases, where the acronym is rather common, adding the fully spelled out form will not add any value but only confuse users. In these cases, the acronym can be used on its own.

Example:

• ANSI (American National Standards Institute)
• ISO (International Standards Organization)
• ISDN
• DSL
• CD
• DVD

Articles

Product Names

• Mozilla product names are used without definite or indefinite articles. They are treated as proper names.

Copyrights and Trademarks

Product names are often trademarked or may be trademarked in the future and are therefore rarely translated.

Before translating any product or component name, please verify that it is in fact translatable and not protected in any way.

Also, bear in mind that the same product may be marketed under different names in different countries.

If in doubt, please contact the Rubric Project Manager.

Translation of Version Strings

• Please use the following guidelines when localizing version strings:

Gender-neutral Translation

In KiArabic, gender is most often never specified. . In a sentence such as “Mwanafunzi wa darasa hilo alisherekea,” you have no linguistic clues as to the gender of the student (mwanafunzi).

Only a few verbs in KiArabic are gender specific. If you need to mention marriage, use a variant of “kufunga ndoa” to indicate that someone is married, rather than “kuoa” (male) or “kuolewa” (female). The other gender-specific verbs involve sexual situations. KiArabic does not distinguish gender for nouns, except for pairs that are explicitly about gender: "man/woman", "boy/girl" mvulana/msichana, "sister/brother" dada/kaka, etc. Example

Genitive

Is used in grammatical contexts to denote special word categories. It is used in formation of compound terms through formation of conjunctions. Nouns can be modified by other nouns or other categories. There is prototypically a head word that comes before the connector and another one following.

Convention 1 (e.g. Attaching a genitive “s” to (trademarked) product names is not feasible, as it could be interpreted as a modification of such names.)

Example:

Localised Term vs. English Term

Inflections

The examples below show how English loanwords inflect for number in KiArabic

Example:

Plural Formation

KiArabic Plurals are grammatical numbers that refer to more than one of the referent in day to day life.

In KiArabic, to form the plural of nouns and adjectives depends on the noun class. KiArabic nouns are divided into 11 classes that generally follow the syntax rules. For most nouns, the prefix before the root tells whether it’s in singular or plural. However, there are some nouns that don’t change in their structure, the change is realized in the syntax. For example we have the noun class of all the nouns that have life, mostly human beings. E.g. Mtu (singular person) watu (plural for people). This class is called M-WA. In this class many nouns have prefix m- in the singular and wa- in the plural. However there are very many irregular nouns that don’t follow this rule. E.g. Rafiki (friend) Daktari (doctor)

Example:

Verbs and Verb Forms

For US English Mozilla voice, verb tense helps to convey the clarity of Mozilla voice. Simple tenses are used. The easiest tense to understand is the simple present, like we use in this guide. Avoid future tense unless you are describing something that will really happen in the future and the simple present tense is inapplicable. Use simple past tense when you describe events that have already happened.

KiArabic verbs are often given in the stem form in dictionaries. Two examples of verb stems are 'lala' meaning 'sleep' and 'sema' meaning speak. Various markers are then added or prefixed to the verb stem to change the meaning. One such prefix is ku which is equivalent to the English infinitive or 'to' form of the verb.

So: ku + verb stem gives the infinitive.

'kulala' means to sleep 'kusema' meas'to speak'

Verbs in KiArabic must end in a suffix and this is shown with the verb 'kujua' meaning to know (verb stem 'jua').

ku (verb prefix) ju (verb stem) a (suffix)

The suffix isn't always 'a' and verbs of Arabic origin end in 'e', 'i' or 'u'. 30

Headings

Headings should convey as much information as possible about the ensuing text to help readers locate information quickly.

Capitalization

• In English headings all nouns, pronouns, adjectives, verbs, adverbs, and subordinate conjunctions (e.g. that, until, which) are capitalized.

In Lists and Tables

• Whenever possible, headings of lists and tables should consist of one or two words, preferably active nouns. They should be concise, even if the source uses a longer phrase.

Hyphenation and Compound formation

General Hyphenation Rules

The hyphen is used to divide words between syllables, to link parts of a compound word, and to connect the parts of an inverted or imperative verb form.

Example:

English Compounds

Generally, compounds should be understandable and clear to the user. Overly long or complex compounds should be avoided. Keep in mind that unintuitive compounds are ultimately an intelligibility and usability issue.

Noun and verb compounds are a frequent word formation strategy in English. Product user interfaces, online help, and documentation contain a number of such examples. However, not all languages use compounding to create complex word meanings.

KiArabic makes frequent use of compounds. However, you should avoid making up new compound terms, unless the meaning is obvious, because end users will usually not have an easy way to disentangle the invented phrase. You should certainly leave spaces between the words that make up a compound, and the use of “-a” (wa/ cha/ la/ za/ ya, etc) will often clarify the meaning of the new term.

Example:

Product Names

Mozilla product names and non-translated feature names are used without definite or indefinite articles in the English language. We treat them in this way;

Product names are often trademarked or may be trademarked in the future and are therefore rarely translated. Occasionally, feature names are trademarked, too (e.g. IntelliSense™). Before translating any application, product, or feature name, please verify that it is in fact translatable and not protected in any way. This information needs to be obtained from the Product Group.

Indexes

Capitalization, Prepositions and Articles

• Avoid starting an entry with a preposition or an article because of their unfavorable effect on the overall sorting order and general legibility of the index.

Prepositions

Translate English prepositions according to their context and not too literally.

Procedures and Syntax

Descriptors

• Use the descriptor (menu, button, command, etc.) only if the source text uses it or if it is needed for clarifying the position of a term in the interface.

Procedural Syntax

• In procedural text, which tells the user to perform certain actions in a certain number of steps, the order in which interface terms are to appear in the translation is usually top to bottom (i.e. menu, command, dialog box, dialog box controls). Maintain this sequence unless there are technical reasons preventing it.

Example:

In the "Extras" menu, click "Settings" and then "Music files".

Status Bar Messages

• Please make sure you adequately capture the meaning of messages when translating.
• If you think a source status bar message is ambiguous, query it to make sure you provide the reader with the right information: if you cannot understand it, they are also not certain to. There is nothing more annoying than "help" that doesn't!

Punctuation

In Lists and Tables

• Do not use a comma after bulleted points.
• If the original source entry contains a period, leave it. If the source text does not contain a period, but you split the translation into several independent sentences, put a period at the end of each sentence.
• The same convention applies to captions and callouts

Comma vs. Period in Numerals

• English uses a period as decimal separator.

Typographic Conventions

In software strings, you must use two double quotes (""xxx"") to denote names within a string. If you only use a single double quotes ("xxx"), this will cause problems with the compilation, as strings are generally denoted by double quotes. Avoid using quotes whenever possible.

دليل ترجمة محتوى فَيَرفُوكس

تهدف هذه الوثيقة إلى تسهيل إنشاء المحتوى وترجمته وإلى دعم التحضير المثالي للمحتوى واتساقه. هذه وثيقة حية تعكس وضعنا الحالي. ومع استمرار تطوّرنا في التعبير عن علامتنا التجارية، فإننا سَنُدخل التحديثات على هذه الوثيقة.

لماذا يُعتبر هذا الدليل مهمًا لترجمة محتوى فَيَرفُكس التسويقي؟

يَهدف هذا الدليل إلى مساعدتك على فهم فَيَرفُكس بشكل أفضل كعلامة تجارية بحيث يتكوّن لديك إحساس أفضل بكيفية التعامل مع مسألة الترجمة في لغتك. بالإضافة إلى ذلك، فإننا سَنُشارك خيارات الكلمات المُحددة والخاصة بالشركة وكيفية تهجئتها لتسهيل عملية الترجمة.

لا تتم ترجمة المحتوى ترجمةً حرفية، ولكن ينبغي أن تعكس الترجمة شخصية علامتنا التجارية وطريقتنا في التعبير عنها بالإضافة إلى تطويع الترجمة بحيث تُناسب الأوجه الثقافية واللغوية. ينبغي ترجمة المقصد العاطفي والمجازي للنص الأصلي ونقله إلى اللغة المترجم إليها.

نبذة عن فَيَرفُكس — من نحن

فَيَرفُكس أكثر من مجرد مُتصفّح. فَيَرفُكس هو علامة تجارية مُفعمة بالتحدي ، يتحدّى الوضع الراهن ويُدافع عن حقوق مستخدمين الإنترنت.

كما أننا نضع حقوق مُستخدمينا واحتياجاتهم على رأس أولوياتنا في كل ما نقوم به. وبما أننا شركة تقنية، فإننا نُعطي الناس الأولوية عن الأرباح.

يجمع فَيَرفُكس كعلامة تجارية بين روح فَيَرفُكس ومنتجاتنا ذات الصلة.

(موزيلا هي المُنظمة غير الربحية التي ترعى فَيَرفُكس.)

وعد العلامة التجارية:

فَيَرفُكس يُحارب من أجلك

ما الذي نُحارب من أجله:

يُحارب فَيَرفُكس من أجل مستخدمينا من خلال تقديم منتجات تُعطي الناس التحكّم والسيطرة على حياتهم على الإنترنت.

المنتجات:

• Firefox Quantum (مُتصفّح مكتبي)
• Firefox Mobile (لنظاميْ تشغيل iOS و Android)
• Firefox Monitor
• Pocket
• Mozilla VPN
• Firefox Private Network (FPN)
• Firefox Relay

الشخصية ونبرة الصوت

من الذين نتحدث إليهم؟

نَصف جمهورنا المُستهدف بأصحاب الاختيار الواعين. وهذا يُشير إلى الأشخاص الذين يُريدون اتخاذ قرارات واعية أو يتخذون قرارات واعية، على شبكة الإنترنت وخارجها.

أصحاب الاختيار الواعين:

• يطرحون تفضيلات ويُقدمون خيارات للمستهلكين بعناية ودراية
• يبذلون ما بوسعهم للتوفيق بين أفعالهم وبين قيمهم ومبادئهم
• مُستهلكون كثيرو المطالب
• يُجرون أبحاثهم الخاصة في العادة لفهم جميع الخيارات فهمًا كاملًا

وضمن أصحاب الاختيار الواعين، توجد مجموعتان نحاول التحدّث إليهما بشكل خاص. المُهتمين بالسرية و عشّاق المغامرات.

المُهتمون بالسرية:

• يُرجّح بشكل كبير أن يكونوا مستخدمي فَيَرفُكس بالفعل
• يُعطون الأولوية للخصوصية ومستعدون لإنفاق الأموال لضمان سلامتهم الرقمية
• يُؤمنون بأن الإنترنت لديه مسؤولية حماية مستخدميه

عُشّاق المغامرات:

• متابعون للصيحات ومبدعون للصيحات
• يُريدون أن يُشاهد أصدقاؤهم ومتابعوهم الخيارات الرائعة التي يختارونها
• يبذلون ما بوسعهم للتأثير على مجتمعهم لتقديم خيارات مدروسة أيضًا

صفات علامتنا التجارية وشخصية العلامة التجارية لفَيَرفُكس

تتحدّد معالم شخصية علامة فَيَرفُكس التجارية من خلال تفعيل هذه الصفات وتطبيقها. وقد تكون إحدى الصفات أكثر بروزًا من صفة أخرى بحسب ما يقتضيه السياق.

نبرة صوتنا

تتميز نبرة صوتنا وخياراتنا اللغوية بأنها:

مسرد المصطلحات / المصطلحات المتكررة (مازال قيد الإنشاء)

في حالات الشك، يُمكن الرجوع إلى transvision search. إلا أن البحث في الغالب يُظهر محتوىً قديمًا من الترجمات في قائمة النتيجة (مع العنوان الرسمي عادةً)، إلا أن هذه الأداة تُعتبر دليلًا في حد ذاتها.

Style Guide Armenian (hy)

Բարի գալուստ Mozilla-ի հայկական համայնքի էջ: Սա մի ձեռնարկ է, որը կօգնի Ձեզ ծանոթանալու և մասնակցելու Firefox-ի, Thunderbird-ի և Mozilla-ի այլ նախագծերի հայերեն թարգմանության հիմնական սկզբունքներին:

Թարգմանության հիմնական սկզբունքները

Նախադասություններ թարգմանելիս կարևոր է հետևել, որ ձեր թարգմանած տեքստը պահպանի անգլերենի բովանդակությունը, սակայն, միևնույն ժամանակ պետք չէ նաև բառացի թարգմանել: Առաջնայինը՝ անգլերեն տեքստի իմաստի արտահայտումն է: Այլ է իրադրությունը կոնկրետ տերմինների կամ առանձին բառերի թարգմանության ժամանակ: Այս դեպքում պարտադիր պետք է հետևել արդեն իսկ մշակված տերմինալոգիային և խուսափել շեղումներից: Առանձին դեպքերում, երբ որևէ տերմի համար առկա չէ հայերեն թարգմանություն՝ պետք է աշխատել գտնել հնարավորինս պարզ և հասկանալի հայերեն բառը:

Հավելումներ

Պետք չէ թարգմանության մեջ ավելացնել լրացուցիչ բառեր, որոնք չկան անգլերենում՝ բացառությամբ այն դեպքերի, երբ իմաստը արտահայտելու համար դա անհրաժեշտ է: Մեկ այլ կարևոր հանգամանք ևս՝ պետք է ուշադրություն դարձել և նաև գոնե մոտավորապես հասկանալ, թե թարգմանվող տեքստը ծրագրային որ հատվածին կամ մասին է վերաբերում և ըստ այդմ &brandShortName; և նմանատիպ տեքստերից հետո դնել -ը, ը և այլն: Եթե խոսքը ապրանքանիշի մասին է, ապա այն չի թարգմանվում հայերենում, նշանակում է պետք է լինի -ը, իսկ եթե խոսքը օրինակ վերաբերում է User (օգտվող)-ին, ապա բնականաբար պետք է գրել ը:

Գրանշաններ

Մշապես պետք է պահել, այսինքն՝ պատճենել և տեղադրել ցանկացած տեսակի կետադրական նշան, չակերտներ, վերջակետեր, թվեր, տառեր-թվեր, բացատներ և այլն: Դրանք պարտադիր են՝ հետագայում խուսափելու համար ծրագրերում խնդիրների առաջացումից:

Տերմինաբանություն

Հայերենի համար շատ կարևոր է ճիշտ տերմինի ընտրությունը: Քանի որ ՏՏ լեզուն հայերենով շատ դեպքերում խորթ է հնչում և այդ տերմինների մի զգալի մասը նորակազմ բառեր են, ապա անպայման հետևեք արդեն իսկ մշակված տերմինների թարգմանություններին:

Տեքստի և բառերի կրճատում

Ինչպես գիտենք՝ անգլերենի համեմատությամբ հայերեն թարգմանությունը շատ դեպքերում ավելի երկար է ստացվում, իսկ հաշվի առնելով այն հանգամանքը, որ լինում են կոնկրետ տողերի համար սահմանված նիշերի սահմանափակումներ, ապա անհրաժեշտ է լինում կրճատել կամ կրճատ գրել հայերեն բառերը: Այդ դեպքում պետք է փորձել կրճատել բառը, սակայն առավելագույնս հասկանալի ձևով:

Կցապիտակներ (Tags)

Mozilla-ում գործածվող կցապիտակները գրեթե միևնույնն են բոլոր ծրագրերի համար: Պետք է հաշվի առնել, որ օրինակ չակերտները չպետք է թարգմանել, այսինքն՝ տվյալ դեպքում չփոխել: Պետք է նույնությամբ պահել նաև տեքստում հանդիպող HTML կոդը: Օրինակներ՝ և </ em> և այլն: Ուշադրություն պետք է դարձնել հատկապես \ n կցապիտակին, որը դնելուց հետո հաջորդող տեքստը տեղափոխվում է նոր տող: Թարգմանելիս պետք է ճիշտ ընտրել այդ կցապիտակի տեղը՝ այս դեպքում չհետևելով անգլերեն տեքստին, այլ իմաստային առումով հարմարեցնելով հայերենին:

Փոփոխականներ

Ոչ մի պարագայում չպետք է թարգմանել փոփոխականները, որոնք կարող են լինել '&', '%', %1$S, %@, #1 և այլն: Դրանք պետք է նույնությամբ պատճենել թարգմանությունում:

Style Guide Bambara (bm)

Introduction

This style guide is intended for translators working on Bambara Mozilla projects. It provides in-depth information about the quality standards expected by Mozilla for the translation of all product components. All translators should read this guide before commencing any translation work.

This guide addresses general translation issues and specifies certain rules of style and usage specific to your language. It should be used as a guideline to avoid common typographic errors, and to maintain consistent terminology and writing style across a project’s components and indeed a product range. The guide should be used in conjunction with the current and previous product-specific glossaries, glossaries of other products of a product range, and the industry standard platform-specific glossaries, such as those provided by Microsoft.

This document may be updated or completed in the course of translation. Where no specific instruction or recommendation is specified, translators should use the phrasing and style that comply with industry standards.

CONTENTS

• General Style Considerations
  • Style guidelines
  • Style guidelines specific to Mozilla products
  • Persona
  • Reference terminology
  • Terminology not found in the glossary or style guide
• Abbreviations, Acronyms, Articles, and Loan Words
  • Abbreviations
  • Common Abbreviations
  • Measurements and Numerals
  • Percentages
  • Digit Groups
  • Filename Extensions
  • Acronyms
  • Localized Acronyms
  • Unlocalized Acronyms
  • Articles
  • Product Names
  • Copyrights and Trademarks
• Non-translated and Loan Words
  • Localized term vs. English term
  • Inflections
  • Singular & Plural
  • Verbs and Verb Forms
  • The use of French loans in the translation
• Word-level Guidelines
  • Headings
  • Capitalization
  • Tonal diacritic
  • Word boundaries
  • Bambara spelling convention choice
  • Intervocalic velars
  • Hyphenation and Compound formation
  • General Hyphenation Rules
  • Compounds
  • In Bambara, compounds are derived from:
  • Applications, Products, and Features Compounds with Acronyms, Abbreviations or Numerals
  • Indexes
  • Prepositions and Articles
  • Key Names
• Sentence-level Guidelines
  • Procedures and Syntax
  • Descriptors
  • Status Bar Messages
  • Punctuation
  • Commas and Other Common Punctuation Marks
  • In Lists and Tables
  • Comma vs. Period in Numerals
  • Special Characters
  • Typographic Conventions
• Appendix
  • Guidelines for the Localization of Error Messages
  • Bambara Style in Error Messages
  • Standard Phrases in Error Messages
  • Error Messages Containing Placeholders

General Style Considerations

Style guidelines

Follow these basic rules:

• Original American English text tends to be rather casual. For Bambara you must adapt your text to the expected audience. It is important to keep sentences as concise and close to the original meaning as possible.
• Try to avoid long, nested sentence constructions. If necessary, break up the original sentence and regroup it syntactically.
• Use wording that is succinct, unambiguous, and free of jargon.
• Produce a translation that sounds as it if was originally written in your language, i.e. avoid following the original source sentence structure too closely.
• Always bear in mind who your target audience is (i.e. an experienced computer user, a beginner, or a combination of both groups).
• Use a consistent style throughout all product components and across a product range, to ensure that all Bambara Mozilla products can be linguistically identified as part of a group of products.

Style guidelines specific to Mozilla products

Please refer to the reference documentation supplied by Mozilla and any Mozilla style guides and make a note of anything significant and specific that should be noted with respect to Firefox OS smartphones.

Persona

Who will be the user of the Mozilla product, translated communication, documentation or web site? [x] Young person (under 30) [x] Teenager

[x] Young woman

[] Child

[x] Male

[x] Female

[] Male or female

[x] Professional person (specify occupation if appropriate e.g. lawyer, teacher)

[x] Non tech-savvy user

[x] Computer geek

[x] Engineer

In Mali, the majority of people who use smartphones are young (under 30 years old), including adolescents. There has been an increase in the use of social media on mobile devices, which are now more affordable.

Among the professionals, we can include teachers, translators, IT professionals, officials (e.g. government agents responsible for the development of the digital economy)

Most people would be interested in using a Bambara localized OS, for a number of reasons:pride over national language (can be taught in schools, at university and, increasingly to adults – this teaching is supported and promoted by the government), falling prices for smartphones and a general association with smart devices/new technology and social status. The users would not necessary need to be ‘tech savvy’ or ‘techie’.

These people would use either formal or colloquial Bambara.

Reference terminology

The following terminology sources should be used as reference in the translation:

Product-specific glossary, to ensure consistency across all product components. Previous version product-specific glossary, to ensure consistency between versions.

Glossaries of other Mozilla products, to ensure cross-product consistency. Microsoft / Apple glossaries, to ensure adherence to the industry standards. It is your responsibility to make sure that you always have the latest Microsoft and Apple glossaries at your disposal. The glossaries can be found at: http://www.microsoft.com/language/en/us/search and https://developer.apple.com/download/more/?=Glossaries.

Terminology not found in the glossary or style guide

Please make a log of any terms not found in the glossary or style guide that are used frequently in the materials. Return this log to Rubric so that the terms can be incorporated into the glossary. This increases consistency in large projects.

Abbreviations, Acronyms, Articles, and Loan Words

Abbreviations

Common Abbreviations

You might need to abbreviate some words in the UI (mainly buttons or options names) due to lack of space. This can be done in the following ways:

It should be noted that Bambara does not frequently use abbreviations and acronyms and consequently there are very few abbreviations and no acronyms found in Bambara. Bambara adopts the French version of some abbreviations e.g. measurement.

The words in the glossary were translated so as to have the smallest possible designations.

Do not abbreviate such words as and, or, something, someone, or any other word that users might not recognize. If you have any doubt, spell out the word rather than using an abbreviation.

Measurements and Numerals

Metric System Commonly Used? Yes

Temperature: Celsius

Note: On units of measure, Bambara adopts the same style and rules as French. Percentages are like in French, e.g. 85 %.

Digit Groups

Country/region: Mali

Decimal Separator: 0,00

Decimal Separator Description: nkɔri

Decimal Separator Example: 5,6 ; 75,05

Thousand Separator: Space

Thousand Separator Description: Space

Thousand Separator Example: 1 543 672; 1 765 234 987

Notes: Bambara follows French in this regard.

Filename Extensions

Filename extensions and graphic formats referenced by filename extensions such as BMP, GIF, HTML, PNG and TIFF must not be translated.

Acronyms

The term acronym refers to words that are made up of the initial letters of the major parts of a compound term if they are pronounced as a new word. Some well-known examples of acronyms are WYSIWYG (What You See Is What You Get), OLE (Object Linking and Embedding), or RAM (Random Access Memory). .

Localized Acronyms

When acronyms are localized, which does not happen often, they take the gender of the first substantive. Example:

• PAO
• CAO
• SGBD

Unlocalized Acronyms

If an acronym must remain in English throughout a manual or other text, the first time it occurs, write its full name in Bambara in normal style followed in parentheses by the acronym and its full spelling in English in italics.

Example:

kunnafoniw ka yɛrɛman yɛlɛman ka taa mansin wɛrɛw kɔnɔ (DDE, Dynamic Data Exchange)

Articles

Product Names

As a general rule, all product names are used without definite or indefinite articles. They are treated as proper names.

Non-translated and Loan Words

Localized term vs. English term

The preferred language in the computer world is English. Therefore, a translator frequently has to decide whether to use the (correct, but obsolete) translation or simply the English word.

Inflections

The examples below show how English loanwords inflect for number in.

Singular & Plural

In Bambara, when the letter w is placed at the end of a word, it marks the plural of the word and is pronounced ou.

Verbs and Verb Forms

The auxiliary to be and to have often translate the same word in Bambara language bɛ. The negative form of the auxiliary bɛ is the word tɛ.

In Bambara, the word ye can also be translated translation of auxiliary be and have.

Auxiliary have also often results in Bambara with the word MA in negative phrases. These various cases cited above should be taken into account by the translator.

The use of French loans in the translation

Considering that the Bambara language is relatively weak in the field of new technology, and seeing as Mali is a Francophone country and that most of the new words in technology are adapted from French (and some uneducated people learning these terms will learn what’s spoken commonly every day, i.e. French), the use of French loanwoards is an acceptable thing. If the word has no meaning in Bambara, or if a Bambara neologism would mean a complicated translation that will not be understood by the majority of the people, French loan words should be used.

Example:

Note: There are words which have several types of translation Bambara and in this case, the translator will select the translation most commonly used by the population.

Example:

Respect of Bambara orthography The French words that end with tion or xion take siyon at the end should be adapted as follows.

Example:

The French words that end with ier take iyɛ at the end should be adapted as follows.

Example:

Note: In Bambara, words that contain a <š> are better replaced it with s unless it forms a minimal pair. In this case we will use sh.

Word-level Guidelines

Headings

Headings should convey as much information as possible about the ensuing text to help readers locate information quickly.

Capitalization

For edition names, both words should be capitalized:

Capitalize only the first letter of the first word in commands, dialog box titles, and dialog box options.

In headings, captions, table and figure titles, use initial capitals for only the first noun, and for proper nouns and interface terms that require it.

Tonal diacritic

There is no need for any diacritics in standard Bambara orthography if we are not marking tone.

Example:

Word boundaries

The merger of the pronoun and / or post-position

Words must be separate so that one can find the various elements of a sentence.

Example:

a bɔama → a bɔ a ma segin'akan → segin a kan

The omission of pronouns

Translators must be careful not to omit pronouns in sentences.

Example:

ma ɲɛ → a ma ɲɛ ka ɲɛ → k’a ɲɛ

Unnecesary marking of suffix

No need to mark the nominalization suffixe <-li/ni>

Example:

làdi'li → ladili

Bambara spelling convention choice

Intervocalic velars

There are cases where it is better to use the form contacted words to use less space. This is acceptable only if the meaning is the same in both variants.

Example: Jidibaga → Jidibaa dɛmɛbaga → dɛmɛbaa

Punctuation marks

Bambara uses the same rules of punctuation as French.

Hyphenation and Compound formation

General Hyphenation Rules

The hyphen is used to divide words between syllables, to link parts of a compound word, and to connect the parts of an inverted or imperative verb form.

When a hyphenated compound should not be divided between lines (e.g., MS-DOS), use a non-breaking hyphen (CTRL+SHIFT+HYPHEN). Both parts of the compound will be kept together on the same line.

Compounds

Noun and verb compounds are a frequent word formation strategy in Bambara. Product user interfaces, online help, and documentation contain a number of such examples. However, not all languages use compounding to create complex word meanings.

In Bambara, compounds are derived from:

Noun + noun e.g. sɛgɛsɛgɛli + buwati = sɛgɛsɛgɛli-buwati Verb + noun e.g. sanji + dɛsɛ = sanji-dɛsɛ Verb + verb e.g. kari + kari = kari-kari

Generally, compounds should be understandable and clear to the user. Overly long or complex compounds should be avoided by verbally expressing the relationship among the various compound components. Keep in mind that unintuitive compounds are ultimately an intelligibility and usability issue.

Note: that English compounds are not necessarily compounds in Bambara. However, English compounds must be translated in a manner that is intelligible to the user and if Bambara translation is narrative in an undesired manner, The English word pronunciation must be the same as that of Bambara but with a little modification.

Applications, Products, and Features

Application/product names are often trademarked or may be trademarked in the future and are therefore rarely translated. Occasionally, feature names are trademarked, too (e.g. IntelliSense™). Before translating any application, product, or feature name, please verify that it is in fact translatable and not protected in any way.

Microsoft product names are usually trademarked and remain unlocalized. Product names and non-translated feature names are considered proper nouns and are used without definite or indefinite articles in English. For instance, attaching a genitive “s” to trademarked product names is not feasible as it could be interpreted as a modification of such names. Additions to a product or component name are either added with a hyphen or a periphrastic construction needs to be used. For example, instead of expressing a possessive relationship by using the genitive marker “s” in English, a periphrastic construction should be used:

1. Microsoft’s products
2. Microsoft products
3. Products by Microsoft

Product names and non-translated feature names should also be treated as proper nouns in Bambara

By contrast, translated feature names are used with a definite or indefinite article as they are not treated as proper names.

Note: that although the two names, Task Manager and Media Player are translatable, it is preferred that they are, in this context, not translated for purposes of clarity because the translated versions of these names will have a potential of losing their meanings since they will be general.

Compounds with Acronyms, Abbreviations or Numerals

The compounds below contain either an abbreviation or a numeral followed by a component name. The abbreviation or numeral is marked in red in the English example. The Bambara example below show how such constructions should be translated.

Note: It is an acceptable principle that when a technical term of the source language does not have a straight equivalent in the target language and all other translation strategies are, for purposes of intelligibility, not applicable, the term should be used as it is in the interest of maintaining the meaning of the term to the user. (Also see the subchapter on English Terminology and the Bambara Terminology for further comments in this respect).

Note: also that the translation of the compounds above is similar in every respect with the translation of other compounds in this chapter.

Indexes

Prepositions and Articles

Articles

Using articles is rare in Bambara. Most of the time, to differentiate the singular and the plural, we must look at the end of the word if it contains a w.

Prepositions

The set-up of a rule for prepositions is not an easy thing in Bambara, because a word can take many forms. Everything depends on the context of the sentence.

Key Names

Bambara adopts French versions.

Sentence-level Guidelinees

Procedures and Syntax

Descriptors

Use the descriptor (menu, button, command, etc.) only if the source text uses it or if it is needed for clarifying the position of a term in the interface.

Status Bar Messages

Please make sure you adequately capture the meaning of messages when translating.

If you think a source status bar message is ambiguous, query it to make sure you provide the reader with the right information: if you cannot understand it, they are also not certain to. There is nothing more annoying than "help" that doesn't help!

Post-positions

If the ... represents an element then it must come before kan. Otherwise we could represent it as O kan (About this).

Punctuation

Bambara follows French punctuation rules. As a general rule, double punctuation signs are preceded and followed by spaces, while single punctuation signs are just followed by one space.

Commas and Other Common Punctuation Marks

• Comma: No space between the word and the comma, a space after the comma. (Except for the decimal point as in 3.14116).
• Point: No space between the word and the point, a space after.
• Ellipsis: no space between the word and the three points, one space after them. Space before them if they replace a word, and space after. Ellipsis character should be used, rather than three separate points.
• Semicolon: a space between the word and the semicolon and after it.
• Colon: a space between the word and the colon, a space after.
• Question mark: a space before that and after it.
• Exclamation mark: a space before and after.
• Hyphen: no space before, no space after.
• Parentheses: A front space, no space inside the parenthesis, and for the closed parenthesis, no space inside and a space after the closed parenthesis.
• Hyphen making parenthesis function ¬: a space before the hyphen, a space after the hyphen, for each.
• Quotation marks: a space before the quotation mark, no space between the quotation mark and the word. No space between the word and the quotation mark and a space after the quotation mark. French quotes: no space between the quotation mark and the word in quotes, and no space after the word in quotes.
• Slash, no space between the bar and the figure or word.
• Hook: A space before the open hook, but not between the hook and the word; no space between the word and the closed hook and a space after.
• Apostrophe: No space before and after the apostrophe.
• Degree: 19° no space after the number and after the degree symbol.
• Symbols: Minute and second 45'or 35'' –there is no space between the symbol and the number and after the symbol.
• The Percentage of symbol: 30 %: a space before, one after.
• The Arithmetic signs + or ? or x, a space before, one after. 2 + 2 = 4
• The Symbols of currencies, measures, time 25 € or 3 m or 30 s a space before, one after.
• Asterisk *: No space before, one after

In Lists and Tables

• Do not use a comma after bulleted points. 8 If the original source entry contains a period, leave it. If the source text does not contain a period, but you split the translation into several independent sentences, put a period at the end of each sentence.
• Never put a period after just one word. The result of this method may be that some entries within one table are with and some entries are without a final period. From a technical point of view this is acceptable. The same convention applies to captions and callouts

Comma vs. Period in Numerals

English uses a period as decimal separator. In Bambara, a comma is used. Do not use a space for this purpose as a space separates the numeral from the abbreviation.

In paper sizes the decimal separator and the abbreviation "in" for inches are kept, since the sizes are US norms and should be represented accordingly.

For thousands, English uses a comma while many other languages use a period (at Microsoft we normally do not use a space for this purpose, but we use a period instead to avoid wrapping problems). In Bambara a comma is used.

Special Characters

Bambara adopts French versions.

Typographic Conventions

Consistent use of typographic conventions in documentation helps users locate and interpret information easily. Generally speaking, the source format should be followed as closely as possible, i.e. terms with a particular formatting in the source should have the same formatting in the translation.

If menu, command, option, etc. Names are highlighted by bold print in the source, use bold print for the corresponding translated terms. If menu, command, option, etc. Names are put in quotes in the source, use quotes for the corresponding terms in the translation.

Note that in software strings, you must use two double quotes ""xxx"" to denote names within a string. If you only use a single double quotes "xxx", this will cause problems with the compilation, as strings are generally denoted by double quotes.

Appendix

Guidelines for the Localization of Error Messages

Bambara Style in Error Messages

It is important to use consistent terminology and language style in the localized error messages, and not just translate as they appear in the US product. New localizers frequently ask for help with error messages. The main principles for translation are clarity, comprehensibility, and consistency.

Standard Phrases in Error Messages

When translating standard phrases, standardize. Note that sometimes the US uses different forms to express the same thing.

Examples:

Error Messages Containing Placeholders

When localizing error messages containing placeholders, try to find out what will replace the placeholder. This is necessary for the sentence to be grammatically correct when the placeholder is replaced with a word or phrase. Note that the letters used in placeholders convey a specific meaning, see examples below:

%d, %ld, %u, and %lu means n/a

%c means n/a

%s means n/a

Examples of error messages containing placeholders:

Checking Web %1!d! of %2!d! means Checking Web n/a

INI file "%1!-.200s!" section means INI file n/a

When localizing error messages containing placeholders, find out what text will replace the placeholder when the user sees the error message. This process is necessary because you must ensure the resulting sentence will be grammatically correct when the placeholder is replaced with a word or phrase. Most source strings have instructions that detail what text will replace the placeholder.

In the English source string, placeholders are found in the position where they would naturally occur in that language. Since in English numerals typically precede the noun, the numeral placeholders typically precede the noun in the source strings. In Bambara, it is the opposite. The noun typically precede the numerals.

The letters and symbols used in placeholder text convey a specific meaning. Please refer to the following table for examples of placeholder text and corresponding error message text that users will see.

Mozilla L10n Style Guide Bengali Bangladesh (bn-BD)

Intro

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.

Available style guide for Bangla:

• Facebook
• Microsoft

Bengali Language

Bengali also known by its endonym Bangla, is an Indo-Aryan language spoken in South Asia. It is the national and official language of the People's Republic of Bangladesh, and official language of several northeastern states of the Republic of India, including West Bengal, Tripura, Assam (Barak Valley) and Andaman and Nicobar Islands. more in Wikipedia

Characters/Alphabet

The Bengali alphabet or Bangla alphabet (Bengali: বাংলা লিপি Bangla lipi) is the writing system for the Bengali language and is the 6th most widely used writing system in the world. The script is shared by Assamese with minor variations and is the basis for the other writing systems like Meithei and Bishnupriya Manipuri. Historically, the script has also been used to write Sanskrit in the region of Bengal.

To know more about Bengali Alphabets [click here](https://en.wikipedia.org/wiki/Bengali_alphabet)

Language-specific Mozilla style

Formality and Tone

Instructions from the early days of Bengli l10n from Ankur Bangla Project read-more

While translating, remember not to kill the language ;-). Do not overdo the translation - do not use Sadhu Basha . Also, when the computer is addressing the user, it is samman-shuchak (karun, balun, etc) while the computer is addressed by karo, balo, etc. If a Bangla equivalent sounds too out of the ordinary - keep the English word (in Bangla script) - it can be always changed/improved later. DO NOT overdo anything.

The language should not be too much formal and bookish. The tone should be less formal and bookish.
The user should be addressed as "আপনি". Machine provide any message should be in "আপনি" tone.
In a case of command machine should be addressed machine as "তুমি".

Natural expression

Handling cultural references, idioms, and slang

Style consistency

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. For example, some brand names should never be translated, such as "Firefox".

To know about branding rules in bn-BD [Mozilla Brand Names and Trademarks](http://wiki.mozillabd.org/index.php?title=Unchanged_Words#Mozilla_Brand_Names_and_Trademarks)

Terminology

Here are a few existing term bases we approve of for software/internet terminology and definitions (though not limited to):

[Microsoft key terms and target languages](https://www.microsoft.com/Language/)

Tips on translating difficult concepts
Developing new term bases
Units and Grammar
Units and Unit Conversion

Date Format

In general in Bangladesh

date format
    dd/mm/yyyy (২৭/১২/২০১৬)
    ১২ জুন, ২০১৬
    পহেলা এপ্রিল

How are the date formats for weeks and months expressed in the following forms:

* Month (Fully spelled)
    * জানুয়ারি
    * ফেব্রুয়ারি
    * মার্চ
    * এপ্রিল
    * মে
    * জুন
    * জুলাই
    * আগষ্ট
    * সেপ্টেম্বর
    * অক্টোবর
    * নভেম্বর
    * ডিসেম্বর
* Month (2 or 3 letters)
    * জানু
    * ফেব্রু
    * মার্চ
    * এপ্রি
    * মে
    * জুন
    * জুলা
    * আগ
    * সেপ্টে
    * অক্টো
    * নভে
    * ডিসে
* Week (Fully spelled)
    * শনিবার
    * রবিবার
    * সোমবার
    * মঙ্গলবার
    * বুধবার
    * বৃহস্পতিবার
    * শুক্রবার
* Week (2 or 3 letters)
    * শনি
    * রবি
    * সোম
    * মঙ্গল
    * বুধ
    * বৃহঃ
    * শুক্র

• Week (1 letters)
  • শ
  • র
  • সো
  • ম
  • বু
  • বৃ
  • শু

Reference material can be [found here](https://en.wikipedia.org/wiki/Date_format_by_country)

Calendar view

রবিবার is considered as the first day of the week in Bangladesh, and শনিবার is the end of the week. শুক্রবার is the day off in Bangladesh.

Time Format

In Bangladesh time is presented as hh:mm

am=পূর্বাহ্ন
pm=অপরাহ্ন

Time also can be presented as in 24 hours format as well.

Short form of Bangladesh Standard Time is BST.

Numerals

Numbers should not be translated. This is applicable for decimals. Comma in numbers should be like 10,00,000.

Currency

Bangladeshi currency should be presented as "টাকা" (Taka). Symbol of the currency is '৳'. Short form of Bangladeshi Taka is "BDT".

Units

Units which is written in full-form, transliterate it in Bengali. Like kilometer can be written as 'কিলোমিটার'। But if it is written in short-form, that should be kept as it is. Like km must be written as km.

Names

Brand names, trademarks, product names should be kept as it is. Like Mozilla, Google, Firefox. Other than that any name can be transliterated.

[Click here for more on names](http://wiki.mozillabd.org/index.php?title=Unchanged_Words#Names)

Address and Postal Code Format

[House no][Area/Street/Village][Post Office][Thana][District][Post Code][Country]
Example: হাউজ নং ৮৩/বি, রোড নং ৪, কামাল আতাতুর্ক এভিনিউ, বনানী, ঢাকা-১২১৩, বাংলাদেশ

To know more about Postcode of Bangladesh [click here](http://www.bangladeshpost.gov.bd/PostCode.asp)

Telephone Number format

When dialing a Bangladesh number from inside of Bangladesh, the format is : "0 - Area/operator code (X) - subscriber number (N)"

When dialing a Bangladesh number from outside Bangladesh, the format is : "+880 - Area/operator code (X) - subscriber number (N)"

The subscriber number is the number unique to each individual telephone/mobile following the area/operator code. The Area/operator codes in Bangladesh are listed below, with a typical number format, where "X" explains the Area/Operator code and "N" explains individual subscriber's telephone/mobile number.

To know more see Wikipedia page [Telephone numbers in Bangladesh](https://en.wikipedia.org/wiki/Telephone_numbers_in_Bangladesh)

Spelling And Grammar Checks

Tense

To know more about Tense in Bengali [click here](https://en.wikipedia.org/wiki/Bengali_grammar#Tense)

Word Forms
Pluralization

Abbreviations

Abbreviations should be kept as it is. No translation no transliteration.

To know more about this [click here](http://wiki.mozillabd.org/index.php?title=Unchanged_Words#Abbreviations)

Acronyms

Abbreviation এ প্রতিটি অক্ষরকে আলাদাভাবে উচ্চারণ করা হয় এবং এটাকে শব্দ হিসেবে পড়া হয় না। কিন্তু Acronyms কে একটি শব্দ হিসেবে উচ্চারণ করা হয় এবং Abbreviation এর মত প্রতিটি অক্ষরকে আলাদাভাবে উচ্চারণ করা হয় না। যেমন SIM এর উচ্চারণ "এসআইএম" এর বদলে "সিম" করা হয়ে থাকে। এ ক্ষেত্রে আমরা শব্দকে উচ্চারণের ভিত্তিতে বাংলা করা যাবে যদি শব্দটি সমাজে বহুল প্রচলিত হয়ে থাকে।

Punctuation

Bengali punctuation marks, apart from the downstroke দাড়ি dari (|), the Bengali equivalent of a full stop, have been adopted from western scripts and their usage is similar: Commas, semicolons, colons, quotation marks, etc. are the same as in English. Capital letters are absent in the Bengali script so proper names are unmarked.

To know more about Bengali alphabets [click here](https://en.wikipedia.org/wiki/Bengali_alphabet)

• Emphasis
• Hyphens and compounds
• Prepositions and articles
• Diacritics and Special characters
• Quotes
• Whitespace
• User Interface Elements
• General Mozilla l10n style
• Accuracy
• Meaning-based translation

Should not be translated

Please see page Unchanged words at MozillaBD wiki.

• Translating culture-specific references
• Legal content
• Fluency

Mozilla L10n Style Guide

• Mozilla L10n Style Guide
  • Intro
  • Language-specific Mozilla style
    • Style
      • Formality and Tone
      • Natural expression
      • Handling cultural references, idioms, and slang
      • Style consistency
    • Terminology
      • Tips on translating difficult concepts
      • Developing new term bases
    • Units and Grammar
      • Units and Unit Conversion
        • Date Format
        • Calendar view
        • Time Format
        • Numerals
        • Currency
        • Units
        • Names
        • Address and Postal Code Format
        • Telephone Number format
      • Spelling And Grammar Checks
        • Tense
      • Word Forms
        • Pluralization
        • Abbreviations
        • Acronyms
        • Punctuation
        • Emphasis
        • Hyphens and compounds
        • Prepositions and articles
        • Diacritics and Special characters
        • Quotes
        • Whitespace
        • User Interface Elements
  • General Mozilla l10n style
    • Accuracy
      • Meaning-based translation
      • Should not be translated
        • Shortcuts and accesskeys
        • Variables
        • Brands, copyright, and trademark
      • Legal content
    • Fluency
  • ​ဘာသာပြန်စတိုင်လမ်းညွှန် (my)
    • မာတိကာ
      • မိတ်ဆက်
      • Pontoon ဆိုင်ရာ
      • အခြားသိကောင်းစရာများ

Intro

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:

• https://help.apple.com/applestyleguide/
• https://www.microsoft.com/en-us/language/StyleGuides?rtc=1
• https://www.facebook.com/translations/style_guides

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

Style

Your localization community's style is largely up to you to define. It is a part of your community's instructions and standards for translating strings within each project type. Style encompasses various elements, such as formality, tone, natural expression, handling cultural references, idioms, or slang, and maintaining consistency with Mozilla and 3rd party branding and style guides. Your localization community should define these style elements for localizing Mozilla projects into your language. Let's go through these main aspects of Style.

Formality and Tone

When determining the formality or tone of a Mozilla l10n project in your language, ask yourself these questions:

Who is the target user for this project and what is their background?
How would a target user for this project expect to interact with this project? For example, would they expect a friendly, casual interaction?
Is formal language appropriate for all of your language's Mozilla l10n projects, or only some of them? Which ones?
Is informal language appropriate for all of your language's Mozilla l10n projects, or only some of them? Which ones?

In fact, localization should not use a level of formality higher or lower than required by this community-defined style guideline. An example of this would be using "click here" (not formal) vs. "please click here" (more formal). Also, the tone employed throughout a l10n project(s) should stay consistent within itself.

Natural expression

Using natural expressions make your localization sound natural to a native speaker. If your translation does not follow the community defined language guidelines for translating content that contains local or natural expressions, this results in a mediocre and/or awkward translation. Teams should be careful to address those and keep them in mind while translating, which is why it is an important section to address in a Style Guide. An example of a natural expression in a translation would be translating the Spanish phrase, "En ocho días." In English, one might translate this as, "in eight days" or "in a week." The latter is the more natural translation, although both could be considered correct.

In this section, form guidelines for how to perform a natural sounding localization. This might take some time and experience to find the right examples to include or create the right guidelines for your language.

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")

Define a policy for handling these cultural references, idioms, and slang that you can make standard across all projects. Consider resources you can refer back to in order to find cultural equivalents and list them in this section of your style guide (e.g., a slang dictionary in your language).

Style consistency

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, your localization community must define whether to translate them. Be extra careful to check on branding rules before deciding to translate a name or not (whether for Mozilla or for a third-party) and to list them here in your community's l10n style guide.

Terminology

Here are a few existing term bases we approve of for software/internet terminology and definitions (though not limited to):

Microsoft key terms and target languages  https://www.microsoft.com/Language/

You should be consistent in the use of existing reliable appropriate term bases in your language. These term bases could be developed and approved by the community, or leveraged from another party that adhere to national, international or local standards for software and internet terminology. Avoid the following:

Inconsistent use of terminology within the project
Inconsistent use of terminology with term base
Inconsistent use of terminology across all of your projects
Using terminology from another subject matter (e.g., don't use medical terminology in Firefox).

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.

Developing new term bases

What is your community's process for identifying and creating a new termbase? Here are a few things to keep in mind:

Avoid overly borrowing English expressions
Referencing another language from the same language family may inspire you to come up with your own terms
Consider the product target audience (age, level of literacy, education, social and economic status)
Will you use loan words from another language or coin new terms in your language to maintain language purity? Is there government requirement or policy to encourage creating new terms for new concepts, or will loan words be sufficient to reach broader masses and expedite new technology adoption?
If there are two acceptable scripts commonly used by the general public, what is the commonly used script on the web or government sites?  What is the script used by major web technology companies?

Units and Grammar

Many elements of unit or grammar do not exist or apply to all languages. If you find one of these elements that does not apply to your language, please remove it from your style guide. For those definitions of units and grammar that apply document the reference used or how it will be applied to the translation.

The translation should strive to achieve proper unit conversions for currency, measurements, etc. for the target audience.

Units and Unit Conversion

Date Format

How are the date formats for weeks and months expressed in the following forms:

1). Fully spelled out 2). 2 or 3 letters  3). Single letter
What is the order of Year, Month and Day?

Reference material can be find here: https://en.wikipedia.org/wiki/Date_format_by_country

Calendar view

   Which date is considered the first day of the week, Sunday or Monday?
   Is Lunar calendar observed?  Other regional calendar observed?

Time Format

How is time expressed in your language? Including 0-24 hr expression, hour, minute and second.

Numerals

How are numerals and percentages expressed in your language? ​ Example: 1.23 (decimal separator) or 1,000 (thousand separator) using comma or period.

Currency

What are other widely used currency and symbols used in your country/language for paid apps.

Units

Do you use the imperial, metric or nautical system for measuring weight, distance, etc.? Source strings will use the imperial system (e.g., miles, pounds, feet, gallons, etc.). Target translations should convert imperial metrics to their measurement system.

Names

What are the order of family name and given name in your language? Here is the guideline on the naming convention from w3c.org:

Address and Postal Code Format

What is the format in your language? ​ Example: most Asian countries start from big to small: [Country] [postal code][state/province][city][district][street number and name][building and suite numbers][addressee] ​ Countries of European languages start from small to big: [addressee][street number and name][building and suite numbers][district][city][state/province][postal code][Country]

Telephone Number format

Space separators between digits can be different for area codes such as State (Province) and City,

Spelling And Grammar Checks

Many languages have national or international standards that define spelling and grammar rules. When defining these rules for your community, make reference to those standards wherever possible. Do you have automated tests for spell checking and grammar? List those tools and dictionaries here and how regularly they should be used.

Tense

Do you have standards for verb forms that indicate or express the time, such as past, present, or future, of the action or state? What is your policy on tense consistency for certain use cases? For example, for phrases that ask a user to make an action (like "Download Firefox"), do you use a future tense, a command tense, or a neutral tense? (See: https://en.wikipedia.org/wiki/Grammatical_tense )

Word Forms

Pluralization

What is the appropriate form of expressing pluralization in your language? List all forms of plural forms and examples if there is more than one. Additional discussions can be found Here. https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_and_Plurals and here: http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html

Abbreviations

How are abbreviations expressed in your language? ​ Example, in English, abbreviations are made by removing most vowels and only using the first 3-5 consonants followed by a period (e.g., abbreviation = abbr.). (see: https://en.wikipedia.org/wiki/Abbreviation)

If your language does not have a standard way of expressing abbreviations, do you simply leave them in English?

Acronyms

Are there standard translations of widely accepted acronyms such as CD, DVD, MB in your language? If not, do they remain in English? (see: https://en.wikipedia.org/wiki/Acronym )

Punctuation

Do you use different punctuation rules in your Firefox localization than what your language standard defines? ​ Example: do you use a period at the end of every user interface element translation or only some? What is the international/national standard for punctuation in your language?

Emphasis

Is there an international/national standard for capitalization in your language?

If so, do those standard rules apply in all product translations?
If this doesn't apply, how do you indicate importance or name of a movie, book title, product UIs (Save, File...) in your language?
How does your language handle the use of bold, italic, or underline types to express emphasis?  ( See: https://en.wikipedia.org/wiki/Italic_type )

Hyphens and compounds

What is the appropriate way of using hyphens and compounds in your language? ( https://en.wikipedia.org/wiki/Compound_%28linguistics%29 )

Prepositions and articles

What is the appropriate form of expressing prepositions and articles in your language?

Diacritics and Special characters

Does your language use any special or accented characters and will they be applied and preserved in sort orders, and other aspects of the translation? (see: https://en.wikipedia.org/wiki/Diacritic )

Quotes

Does your language have a standard use for quotation marks, parenthesis, or brackets?

Whitespace

Does your language require the use of white space around words, sentences, paragraphs, etc.? If so, in what ways? (see: https://en.wikipedia.org/wiki/Sentence_spacing_in_language_and_style_guides )

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 each word. Limit to one or two words. Use verbs that precisely describe the button's action. For example, "Cancel", "Clear History", "Add Email", "Select All", 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.

General Mozilla l10n style

Accuracy

Meaning-based translation

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.

Should not be translated

Shortcuts and accesskeys

In Firefox and other software it's possible to use keyboard shortcuts to invoke a specific command. For example, to open a file in Firefox you can press the combination of keys CTRL+O (Cmd+O on Mac). The accelerator key depends on the operative system, but the letter itself is normally localizable. This is what is called a shortcut, or commandkey. For example, the Open File… menu item is stored as

<!ENTITY openFileCmd.label "Open File…">
<!ENTITY openFileCmd.accesskey "O">
<!ENTITY openFileCmd.commandkey "o">

The commandkey is stored in openFileCmd.commandkey (sometimes the string has .key in the identifier). Normally you should not localize this key, since shortcuts are often common across the entire operative system (e.g. CTRL+S to Save) or similar products (CTRL+T to open a new tab in most browsers). But it needs to be localized if the letter is not available in your keyboard layout. For example, in Italian the character [ can be accessed through ALT+è, a command key [ would not work.

In the code fragment above you see also an accesskey defined for Open File…. Accesskeys are used to access a UI element from the keyboard. Example: if File menu has an accesskey F, and the Open file… menu has O, you can press ALT+F to access the menu, and then O to open a file.

If the label is File, and the accesskey is F, it will be displayed as "File" on Windows and Linux, with an underscored F. If the accesskey was "O", so a character not available in the original label, it will be displayed underlined between parenthesis: "File (O)".

One important thing to determine is if, for your locale, it makes sense to have localized accesskeys: for example, if most users will use a keyboard with a different layout (English), it might make sense to keep the English original accesskey instead of using a letter available in your localization.

Accesskeys, like commandkeys, have their own lines within .dtd and .properties files and are usually identified by .accesskey in the string ID.

Variables

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 American 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.

[Add a note about Mozilla culture.]

Legal content

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.

Fluency

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.

​ဘာသာပြန်စတိုင်လမ်းညွှန် (my)

မာတိကာ

• မိတ်ဆက်
• Pontoon ဆိုင်ရာ
• အခြားသိကောင်းစရာများ

မိတ်ဆက်

Mozilla ထုတ်ကုန်များ ဘာသာပြန်ရာတွင် အောက်ပါ အချက်အလက်များကို ကြိုတင်သိရှိ ထားခြင်းသည် ဘာသာပြန်ခြင်း ကို ပိုမို တိကျစေပြီး လျှင်မြန်လွယ်ကူစေပြီး ​ထုတ်ကုန်များ၏ သုံးဆွဲခြင်းအား ပိုမိုကောင်းမွန်စေပါသည်။

Pontoon ဆိုင်ရာ

• [ _ , -’;`!] Punctuation ပုဒ်ဖြတ်ပုဒ်ရပ်။ ။စာတစ်ကြာင်းတွင် ပုဒ်ဖြတ်ပုဒ်ရပ်များ ပါနေပါက သင့်လျော်သော ဗမာစာ ပုဒ်ဖြတ်ရှိပါက အသုံးပြုနိုင်ပြီး မရှိပါက ၎င်းမူရင်း ပုဒ်ဖြတ် ပုဒ်ရပ်ကို ပြန်လည်ကူးယူနိုင်ပါသည်
• [ <a href="%(link)s"></a> ] XML Tags။ ။ စာကြောင်းအား ဘာသာပြန်ဆိုပြီးပါ က ၎င်းတို့အား သင့်လျော်သော အချက်အလက်အား ဝန်းရံ ကူးယူပေးပါ၊ XML tags အများစုသည် ဝက်ဘ် ပေါ်သို့ အခြား တစ်နေရာသို့ ခေါ်ဆောင်သွားလေ့ရှိပြီး ဝန်းရံခံရသော စာစုသည် ၎င်းသယ်ဆောင်သွားမည့်နေရာ အကြောင်းသို့ ဆီလျော်သော စာစု ဖြစ်ရမည်။
• [ FQA ] စာလုံးအကြီး စကားစုများ။ ။ ၎င်းတို့သည် အများအားဖြင့် အရေးကြီးသော ဘုံအသုံးအနှုန်းများ ဖြစ်သည့် အပြင် အတိုကောက်များ လည်း ဖြစ်သည့် အတွက် ဘာသာမပြန်ဆိုပဲ ပြန်လည် ကူးယူပေးသင့်ပါတယ်။

အခြားသိကောင်းစရာများ

Style Guide Cebuano (ceb)

Intro

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.

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).

Language-specific Mozilla style

Rule of Thumb

• DO NOT translate technical terms to Cebuano.
• DO NOT translate proper nouns such as company brands and trademarks to Cebuano.
• DO NOT transliterate. In Cebuano, words are spelled in accordance to how a Filipino enunciates them; examples include drayber (“driver”), diskusyon (“discussion”) and iskul (“school”). Alternatively, words are spelled as they were in the source language. In a strictly formal Cebuano translation, purists resort to transliteration only when source words—particularly technical, scientific, medical and legal word forms — definitely have no direct, exact and accurate equivalents in the target language. For uniformity sake, we should avoid transliterating.
• LEAVE AS IS words, phrases or terms that are hard to be translated in Cebuano, particularly the technical ones (DO NOT transliterate).

Style

The Mozilla Philippines Community localization style encompasses various elements, such as formality, tone, natural expression, handling cultural references, idioms, or slang, and maintaining consistency with Mozilla and 3rd party branding and style guides. The Mozilla Philippines Community define these style elements for localizing Mozilla projects.

Formality and Tone

• Target users of this project are people who speak and read Cebuano.
• Formal language version of Cebuano is appropriate for all Mozilla L10n projects.

Content Principles

• Keep it simple

  • Stick to common words that people use in everyday speech.
  • Be concise. Write short sentences that are easy to understand.

• Get to the point

  • Keep terms and messaging consistent across all channels, on and off Mozilla.
  • Don't bury information or gloss over it.
  • Don't use language that's vague or possibly misleading.

• Talk like a person

  • Translate like you're talking to someone one-on-one. Minimize the use of online translation tools. Translate naturally.
  • Stay neutral. Avoid language that's opinionated, cutesy, irreverent or otherwise over the top.
  • Don't sound like a robot. Even the smallest bits of interference content should be approachable.

• Be brief

  • Use as few words as possible while still being clear.
  • Make sure every word has a job to do.
  • Replace jargon with everyday terms.

Natural expression

Using natural expressions make our localization sound natural to a native speaker.

• Use the "i-[verb]" format during translation:
  • [EN] Bookmark this page. | [TL] i-Bookmark ni nga page.
  • [EN] Cut | [TL] i-Cut
  • [EN] Paste | [TL] i-Paste
  • EXCEPTION: [EN] Copy | [TL] Kopyaha

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:

• Use as is.
  • If the the phrase in question is considered a noun, use as is - eg. "The kick-off meeting is about to start" is translated to either of the following
    • "Magsugod na ang kick-off meeting."
    • "Ang kick-off meeting kay magsugod na."
    • "Sugdan na ang meeting para kick-off."
• Condense it into its most basic form in Cebuano, eg. refer to it as "meeting". Thusly, "The kick-off meeting is about to start" can also be translated loosely as
  • "Magsugod na ang meeting."

Style consistency

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, your localization community must define whether to translate them. Be extra careful to check on branding rules before deciding to translate a name or not (whether for Mozilla or for a third-party) and to list them here in your community's l10n style guide.

Terminology

The Mozilla Philippines L10n Term Bases and Glossary is under development as Project ATOMPH (App for the Translation Of MozillaPH).

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 [2]
• 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.

Units and Grammar

For the sake of uniformity, the following formats are to be used in MozillaPH L10n:

Date

• Calendar / Era: Roman / Christian (Anno Domini, AD)

• Name of Days: English

  • Monday
  • Tuesday
  • Wednesday
  • Thursday
  • Friday
  • Saturday
  • Sunday

• Name of Days: Cebuano

  • Lunes
  • Martes
  • Miyerkoles
  • Huybes
  • Biyernes
  • Sabado
  • Domingo

• Short Name of Days: English

  • Mon
  • Tue
  • Wed
  • Thu
  • Fri
  • Sat
  • Sun

• Short Name of Days: Cebuano

  • Lun
  • Mar
  • Mer
  • Huy
  • Ber
  • Sab
  • Dom

• Name of Months: English

  • January
  • February
  • March
  • April
  • May
  • June
  • July
  • August
  • September
  • October
  • November
  • December

• Name of Months: Cebuano

  • Enero
  • Pebrero
  • Marso
  • Abril
  • Mayo
  • Hunyo
  • Hulyo
  • Agosto
  • Septiyembre
  • Oktubre
  • Nobiyembre
  • Disyembre

• Short Name of Months: English

  • Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec

• Short Name of Months: Cebuano

  • Ene
  • Peb
  • Mar
  • Abr
  • May
  • Hun
  • Hul
  • Ago
  • Sep
  • Okt
  • Nob
  • Dis

• Year Format: English

• Default Short Date Format: MM-dd-yyyy

• Currency

  • Symbol: PHP
  • Format: PHP x,xxx.xx

• Time

  • Time Format: English
  • 24-hour Format: NO (12-hour format)
  • Time Separator: colon (:)
  • String for AM Designator: AM
  • String for PM Designator: PM
  • Century: use "ika-" followed by the number (e.g. ika-21)

• Number

  • When written as English Roman Numeral: as is.
  • When used as part of a sentence (spelled-out) or as an ordinal number: Translate to Cebuano
  • Examples:
    • [EN] Close one tab. | [TL] Isara ang usa ka tab.
    • [EN] Close the second tab. | [TL] Isara ang ika-duhang tab.
  • When written as part of a telephone number: as is. Addresses
  • Country / Region:
  • [EN] Republic of the Philippines | [TL] Republika ng Pilipinas
  • [EN] The Philippines | [TL] Pilipinas
  • Address Format:
    • House or Building Number
    • Building Name
    • Street Name
    • Village or Subdivision Name
    • Barangay Name
    • City or Town Name
    • Province Name
    • Postal Code

Measurement Units

Follow the rules on how to translate numbers

Percentages

The Cebuano language follows the English rules for percentages. In Mozilla localization, the percentage symbol (%) is frequently used a placeholder. DO NOT modify or remove placeholders. Follow general software localization guidelines and rules.

Spelling And Grammar Checks

Spelling checks will be part of Project ATOMPH. Grammar checking tools and guides: https://languagetool.org/ http://www.aclweb.org/anthology/W11-3402

http://learn101.org/cebuano_grammar.php
https://www.gutenberg.org/files/42026/42026-h/42026-h.htm
http://ilanguages.org/cebuano_grammar.php

Word Forms

Pluralization

In Cebuano/Filipino, we use the term "mga" before a noun to denote the common pluralization form:

• Example: [EN] Letters | [TL] Mga letra
• Example: [EN] Bookmarks | [TL] Mga Bookmark

Abbreviations

Here are some of the commonly used abbreviations in Cebuano/Filipino:

• [EN] et cetera = etc. | [TL] ug uban pa = ubp.
• [EN] example = ex. | [TL] pananglitan = eg.

"Pananglitan" does not have its short form. Instead, the Latin short form "eg" (exempli gratia) is used.

Acronyms

English acronyms can be used in Cebuano/Filipino for simplicity and practicality.

Punctuation

Cebuano/Filipino follows the universal standards in the use of punctuations.

Emphasis

• Each sentence in Cebuano/Filipino begins with a capital letter.
• Proper nouns are written with their first letters capitalized.

Hyphens and compounds

Cebuano/Filipino respects the English standards on the use of hyphens and compounds.

• Use a hyphen in repeated words that are intended to emphasize repetition of action; to show similarities or likeness. Eg

  • lakaw-lakaw
  • piyong-piyong
  • sulat-sulat

• Do not use hyphens in repeated words that are considered root words and cannot stand on their own. Eg.

  • bukubuko

  • lapalapa

  • taudtaod

  • Exceptions: Use a hyphen for words with different meaning. Eg.

    • Lapulapu (a person/hero) vs lapu-lapu (a kind of fish)
    • Lainlain (different, assorted) vs lain-lain (set aside)
    • laway (saliva) vs law-ay (lewd)

• Do not use a hyphen when the repeated word is used as a proper noun. Eg.

  • Lapulapu
  • kasingkasing
  • habalhabal

• Do not use a hyphen when the repeated word is a root word. Eg.

  • Lumlom
  • suksok
  • luglog

A hyphen is necessary to separate "g" from prefixes like "mag" when directly followed by a vowel. Eg.

• mag-unay
• mag-abay
• nag-utro

Prepositions and articles

(This section to be added soon.)

Diacritics and Special characters

An official spelling system that uses diacritical marks for indicating long vowels and final glottal stops was introduced in 1939. Although it is used in some dictionaries and Cebuano/Filipino learning materials, it has not been generally adopted by native speakers.

Quotes

Cebuano/Filipino follows the Universal Standard for quotes and brackets.

Whitespace

Cebuano/Filipino requires a space in between words and after each punctuation mark.

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 each word. Limit to one or two words. Use verbs that precisely describe the button's action. For example, "Cancel", "Clear History", "Add Email", "Select All", 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.

General Mozilla l10n style

Accuracy Meaning-based translation 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. Should not be translated Shortcuts and accesskeys

In Firefox and other software it's possible to use keyboard shortcuts to invoke a specific command. For example, to open a file in Firefox you can press the combination of keys CTRL+O (Cmd+O on Mac). The accelerator key depends on the operative system, but the letter itself is normally localizable. This is what is called a shortcut, or commandkey. For example, the Open File… menu item is stored as

<!ENTITY openFileCmd.label "Open File…"> <!ENTITY openFileCmd.accesskey "O"> <!ENTITY openFileCmd.commandkey "o">

The commandkey is stored in openFileCmd.commandkey (sometimes the string has .key in the identifier). Normally you should not localize this key, since shortcuts are often common across the entire operative system (e.g. CTRL+S to Save) or similar products (CTRL+T to open a new tab in most browsers). But it needs to be localized if the letter is not available in your keyboard layout. For example, in Italian the character [ can be accessed through ALT+è, a command key [ would not work.

In the code fragment above you see also an accesskey defined for Open File…. Accesskeys are used to access a UI element from the keyboard. Example: if File menu has an accesskey F, and the Open file… menu has O, you can press ALT+F to access the menu, and then O to open a file.

If the label is File, and the accesskey is F, it will be displayed as "File" on Windows and Linux, with an underscored F. If the accesskey was "O", so a character not available in the original label, it will be displayed underlined between parenthesis: "File (O)".

One important thing to determine is if, for your locale, it makes sense to have localized accesskeys: for example, if most users will use a keyboard with a different layout (English), it might make sense to keep the English original accesskey instead of using a letter available in your localization.

Accesskeys, like commandkeys, have their own lines within .dtd and .properties files and are usually identified by .accesskey in the string ID. Variables

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 American 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.

[Add a note about Mozilla culture.] Legal content

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. Fluency

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.

Mozilla l10n Style Guide - Chinese Simplified (zh-CN) - 中文（简体）本地化翻译须知

Content

• SUMO Style Guide - Chinese Simplified - 中文（简体）本地化翻译须知

Firefox 本地化文案指南

本文档旨在指导文案的创建和本地化，同时提供充足的背景信息，并帮助规范化。这是一份实时更新的文件，体现 Firefox 的当前状况。随着品牌表达的不断演进，我们将持续更新此文档。

为何本指南对 Firefox 营销文案的本地化至关重要？

本指南旨在帮助您更好地了解 Firefox 品牌，进而更清楚如何使用您的语言翻译出理想的文案。此外，为了方便本地化过程，我们将分享 Firefox 特有的固定词汇选择和拼写。

我们的文案不提倡逐字逐句翻译，而应能反映品牌个性和语气语调，并从适用的文化和语言角度进一步优化。源文本的情感和比喻意图应以适用目标语言的方式表达出来。

关于 Firefox——我们是谁

Firefox 不仅仅是浏览器。Firefox 是一个 挑战者品牌，致力于挑战不理想的现状并倡导用户的在线权利。

将用户的权利和需求放在首位的理念，体现于我们所做的每一件事之中。作为一家科技公司，我们始终将用户置于利益之上。

我们将 Firefox 的 品牌精神 融入到相关产品中。

（Mozilla 是推出 Firefox 的非营利组织。）

品牌承诺：

Firefox 捍卫您的权益

我们捍卫什么：

Firefox 创建让人们能控制和管理网络生活的产品，来捍卫用户的权利。

产品：

• Firefox Quantum（桌面浏览器）
• Firefox 移动版（适用于 iOS 和 Android）
• Firefox Monitor
• Pocket
• Mozilla VPN
• Firefox Private Network (FPN)
• Firefox Relay

品牌个性和语气语调

我们的目标受众是？

我们将 Firefox 的目标受众描述为自主选择者（Conscious Chooser），指的是在线上或线下自主做出或想要自主做出决定的人。

自主选择者：

• 发展出自己的偏好，并慎重自主地做出消费选择
• 努力让自己的行为与价值观和理想保持一致
• 高要求的消费者
• 经常自主研究，以求充分了解所有选择

在自主选择者中，有两类群体是我们要特别沟通的对象。 重视隐私的群体 和 勇于尝新的推广者。

重视隐私：

• 很可能已成为 Firefox 用户
• 优先考虑保护隐私，并愿意花钱确保自己的数字安全
• 认同互联网有责任保护其公民

勇于尝新的推广者：

• 潮流追随者和潮流引领者
• 希望他们的朋友和关注者见证他们正在做出的明智选择
• 努力影响他们的社区做出同样深思熟虑的选择

Firefox 的品牌特质和品牌个性

Firefox 的品牌个性由这些相互交融、相辅相成的特性组成。在不同的语境中，一项特性可予以突显或淡化。

语气语调

我们的语气语调和语言选择包括：

词汇表/经常出现的术语（正在制作中）

如遇到不确定的表达，可使用 transvision 搜索。但由于搜索结果列表中经常会显示旧版翻译（通常带有正式地址），因此该工具仅可作为参考。

Style Guide for Simplified Chinese（zh-CN）- 中文（简体）本地化翻译须知

本文由 SUMO 中文 （简体）本地化团队草拟，意在统一本地化文本的翻译格式。请 SUMO 志愿者认真学习。如果有疑问，请在 Github 上提问，或在本地化论坛跟帖。

翻译内容

0. 列在本地化状态面板的需要更新和需要翻译的文章都需要从英文翻译为中文。
1. 标题、缩略名、关键字、摘要和内容均需提供中文翻译。
2. 如果可能，链接尽量指向中文。
3. 如果可能，图片和截图也需本地化。在上传文件时，文件名可以与英语文章中的文件名相同，语言请选择简体。
4. 如果可能，视频应该配上中文字幕。
5. 诸如 [[Image:Properties dropdown for saved searches]] 的原文不用翻译。
6. 诸如 [[Global Search|Global Search]] 的原文应该翻译为 [[Global Search|全局搜索]]。
7. 诸如 [http://forums.mozillazine.org/ mozillaZine forums] 的原文应该翻译为 [http://forums.mozillazine.org/ mozillaZine 论坛]。
8. 译文应力求正确，简明易懂。
9. 译文许可证保持和原文一致。

译文格式

1. 段落尽量和原文一致：段首不必空出两个字，段与段之间空一行。
2. 中英文混合时应在中英文之间留空格。
3. 其他格式使用原文格式。

标点符号

1. 使用中文标准全角标点符号，详见 GB/T15834—2011《标点符号用法》。
2. 文字与标点符号之间不要留空格。
3. 日期、版本号请使用阿拉伯数字。

翻译流程

1. 在本地化状态面板选中要翻译或更新的文章之后，点击其后的需要翻译或需要更新的按钮即进入翻译界面。
2. 然后就可以自己翻译或更新该文章。请注意及时点击页面底部的保存为草稿按钮。
3. 翻译全部完成后，自己检查合格后，请再点提交以供审核按钮。请在修订摘要中写明是：初次翻译或者是根据更新xxxxxx调整翻译。其中xxxxxx是文章的修订版本，在页面上部。
4. 如果文章较长，自己需要多次提交，请在未完成的提交的修订摘要中写明：初次翻译。未完待续。
5. 具有审核资格的成员，可以点击待审核按钮审核提交的翻译。如果有问题，请写明意见给译者并不予通过；如果没问题，请鼓励译者并通过。

统一翻译词汇

此处，收集整理了一些词汇的统一翻译，大家可陆续添加或提出意见。

Style Guide Chinese (zh)

若需分享此文件，可使用 http://bit.ly/MozTW-L10nStyles

這是由 MozTW 維護的 Mozilla 正體中文（台灣）在地化樣式與翻譯規範文件。除非另有定義，否則這份文件所定義的格式會使用在所有由 MozTW 維護的 Mozilla 產品與網頁內容，在您開始進行貢獻前請先詳讀。若對以下格式有所疑問或意見，請寄信到 moztw-general@googlegroups.com 並副本通知 l10n owner，或於 MozTW 討論區提出意見，謝謝。

This is the style guide of Mozilla’s Traditional Chinese (Taiwan) [zh-TW] locale. Except noted elsewhere, this style would apply to all MozTW Projects and Mozilla projects/contents maintained by MozTW. Please read carefully before starting contributing. Should you have any question or concern, or if you want to revise, please raise discussion in moztw-general@googlegroups.com and CC l10n owner, thanks.

共同項目

1. 需準確表達原文含意，避免翻譯後造成的模糊性或過度翻譯，若譯文反而讓人看不懂不如不要翻。
2. 不要使用機器翻譯。亦請注意需符合台灣人常用的語法。（例：o網路 x互聯網）
3. 可適度使用成語，但請力求淺顯易懂。
4. 看不懂的字 / 詞請上 mailing list 問人或上網搜尋，或暫時擱著 / 標記為 fuzzy。
5. 可適度參考其他廠商的翻譯樣式/內容，但不一定要照著翻（為求一致除外）。

• Microsoft: https://www.microsoft.com/en-us/language/StyleGuides?rtc=1

6. 不必句對句、字對字翻譯，可適度依照文化或通順程度或前後語境調整句子順序或作刪減，但這種情況不得與第 1 點牴觸。

• 例如：英文句法與中文句法常是前後顛倒，請適度調整。

7. 遇到 "you" 時，一般情形下使用敬語「您」。若原文沒有那麼嚴肅可視情況使用「你」，但產品內仍應使用「您」。
8. 翻譯 Mozilla 產品時，需注意是否有 LOCALIZATION NOTE。當中會有該行原文與譯文的描述。若當中包含 DONT_TRANSLATE 的描述時，請勿翻譯。
9. 若遇到長原文、有換行符號的原文或 C-Format 的原文內容，可適度依照譯文增減行數，但翻譯完需特別測試譯文是否會被截斷或影響 UI。
10. 中文沒有複數型，遇到諸如 "#1 review;#1 reviews" 的原文，請忽略複數部分（後半）。

• 但仍需考慮這一句有沒有被塞入不同數量的可能

11. 注意中英文的 and / or 意義可能相反，尤其是反向表列的時候。
12. 注意 Gettext 的跳脫符號 \，例如 "%s" 應翻譯為「%s」，但若能確定該參數會顯示的內容語言非中文時則保留使用跳脫符號與引號。
13. 注意用詞的一致，若不知道該怎麼翻可至 Transvision 尋找 Translation Memory。

商標/品牌/產品

1. Mozilla 商標/品牌（例：Mozilla Firefox）：不翻譯
2. Mozilla 產品功能（例：Firefox Account、Private Browsing、Sync）：看前後文意而定，但商標/品牌本身仍不翻譯

• 可翻譯成「Firefox 帳號」、「隱私瀏覽」；Sync 亦可譯為「同步」、「同步功能」

3. 在程式內被寫死，以字串替代的名稱：不翻譯

• 例如：Firefox 會依照 release channel 的不同，在產品內以 Firefox、Aurora、Nightly 取代 &brandShortName; 變數

4. 其他公司、品牌：原則上不翻譯，但看情況而定。

• 例如 Microsoft 可視情況在 SUMO 文件內翻譯為「微軟」，但不將「Microsoft Edge」翻譯為「微軟 Edge」。

標點符號

1. 使用中華民國教育部出版之《重訂標點符號手冊》修訂版當中的標點符號。
2. 中文字、標點符號與半形英數、符號字元間需用半形空格隔開，但與全形符號間則免。

• 例如：「這是 Firefox」的「是」與「F」間有使用空格隔開，而「對於使用者，Mozilla」當中的「，」與「M」間則沒有空格。

3. 無論句子語言為何，句尾冒號使用半形冒號「:」，而非全形冒號「：」。
4. 依照文字語言使用相對應的標點符號。

• "." 作為句點應譯為「。」、" 作為引號，應翻譯為「」。
• 刪節號應譯為「…」(U+2026)，可使用一組就好。遇到原文使用三個點(“...”) 時可報 Bug 修正。

SUMO

1. 文章的 slug（網址後面的 seo 文章 id）不須翻譯，直接複製英文版即可。
2. 若不小心弄出了 slug 錯誤的文件，請聯絡 L10n 團隊編輯將錯誤的文件砍除，並修正連結。
3. 語意正確度、不漏譯、標點符號正確為先，文章的連貫性與通順度次之。不要有沒必要的空格或是零碎的句子。
4. 未完成翻譯前若需先送出手上的文件，請在送出審核前描述編修內容時勾選 "This edit does not make this article up to date. The English differences should not change on the next edit."，下次進行翻譯時將不會自動取回最新的原文。
5. 文件中若提及某軟體或產品內的功能，應依照該軟體內的文字翻譯。
6. “Warning: ”譯為「警告: 」、"Note: " 譯為「註: 」、"Tip: " 譯為「秘訣: 」

MDN

1. 請查閱 MDN 中文翻譯指引

測試 / QA

1. 注意以動名詞開頭的句子在中文語境下的型態。

• 例："Installing" 可能需翻譯為「安裝中」或「安裝」。

2. 注意英文句子中子句順序與中文不同的情況。
3. 注意一字多義的情況，若語句怪怪的或不通順可發信討論。
4. 注意字串長度，看看譯文是否會被截斷。若無法直接透過 l10n 調整則可報 Bug 修正。
5. 遇到樣式、排版或是因為中文缺少好用的 Web Font 而造成的不美觀，可請 l10n owner 聯絡專案負責人修正。
6. 注意日期時間格式是否符合使用習慣。
7. 可調整 ordered arguments 在句中的順序。

• 例："Downloading %1$d of %2$d" 視長度而定，可翻譯為「正在下載 %2$d 個檔案當中的第 %1$d 個」或「正在下載 %1$d 個／%2$d 個檔案」。

8. 翻譯之後可重新閱讀幾遍，看看譯文通不通順，再行修飾。

• 同一句裡面不要重複出現相同的主詞，某些數量與量詞亦可省略，例如：”If you lost your password” 可翻譯為「若您忘記了密碼」而非「若您忘記了您的密碼」

MozLinks

1. 開始翻譯時請在標題時間前面加上「[翻譯中]」，文章翻譯完成後改成「[已翻譯]」。翻譯完成後 Mail 至 mozlinks-zh-editor@googlegroups.com 通知編輯已完成某篇文章翻譯。
2. 將翻譯內容寫在轉貼原文下方的 ”中譯：（請在下方翻譯）” 區塊；翻譯區塊下的原文、授權等內容應放在翻譯內容的最後，翻譯者不應做任何更改。
3. 編輯內容如遇連結或其他語法請參考 Markdown 語法編輯。

• ”MozLinks” 需要 “http://mozlinks.moztw.org/” 連結，則翻譯內容描述為”MozLinks”
• ”MozLinks” 需要使用標題二的字型，則描述應為 ”##MozLinks”
• “MozLinks” 是清單內的其中一項內容，則描述應為 ”- MozLinks” 或 “* MozLinks”

4. 文章翻譯者應在 φ [ ] 翻譯 - [ ] 編輯 當中，前者的 [ ] 翻譯 方框改成自己的名字；編輯的方框則是留給校閱文章的審核者使用。

Firefox 文案本地化指南

本文件旨在促進文案創作和本地化，並為萬全準備和一致性提供支援。這是一份與時俱進的文件，其反映的是我們當下的狀況。隨著品牌表達方式不斷演進，我們也會隨時更新這份文件。

為什麼這份指南對 Firefox 的行銷文案本地化很重要？

本指南旨在幫助您更了解 Firefox 這個品牌，才能更清楚如何使用您的語言進行翻譯。此外，我們也會分享既有的公司特定詞彙選擇和拼寫方式來促進本地化流程。

我們的文案不應按照字面意思進行直譯，而應該要反映出我們的品牌個性和基調，並針對文化和語言角度加以適度優化。目標語言要能適當地呈現出原文的情感和比喻。

關於 Firefox — 我們是誰

Firefox 不只是瀏覽器。Firefox 是一個 挑戰者品牌，我們要挑戰現狀，並為使用者的線上權益發聲。

我們做的每一件事，都將使用者的權利和需求視為首要之務。作為一家科技公司，我們始終以人為本，置於利益之上。

Firefox 這個 品牌 結合了 Firefox 精神和我們的相關產品。

(Mozilla 是 Firefox 背後的非營利組織)

品牌承諾：

Firefox 為您而奮鬥

我們的奮鬥目標：

Firefox 透過建立讓人們能夠自行控管線上生活的產品，來為我們的使用者奮鬥。

產品：

• Firefox Quantum (桌機瀏覽器)
• Firefox Mobile (iOS 與 Android 適用)
• Firefox Monitor
• Pocket
• Mozilla VPN
• Firefox Private Network (FPN)
• Firefox Relay

個性和基調

我們的對象是？

我們將目標族群描述為「明智的決定者」。這是指無論在線上或線下，都能做出 (或希望做出) 明智決定的人。

明智的決定者：

• 會探索喜好，也會仔細並明智地做出消費者選擇
• 努力使自己的行為與自身的價值觀和理想相互協調
• 是擅長要求的顧客
• 常自己做研究，以充分了解所有的選項

在「明智的決定者」中，有 2 種人是我們特別想去交流的。 「機密守護者」 及 「冒險強化者」。

機密守護者：

• 很多可能已經是 Firefox 使用者
• 優先考慮隱私，且願意花錢來確保自己的數位安全
• 相信網際網路有責任保護它的網民

冒險強化者：

• 潮流追隨者和趨勢設定者
• 希望朋友和粉絲都能見證他們做出的好選擇
• 努力影響其自身的社群，並做出深思熟慮下的選擇

我們的品牌屬性和 Firefox 品牌個性

Firefox 品牌個性是由這些屬性的互動方式來定義。根據內容而定，屬性可以更加強化或稍微減弱。

調性

我們的語氣和語言選擇是：

詞彙表／重複詞語 (進行中)

在有疑問的情況下，也可以查詢過渡搜尋。但是，由於搜尋結果清單通常會顯示較舊的翻譯版本 (大部分稱謂較為正式)，因此這個工具僅作為指南參考。

Style Guide Czech (cs) / Překladatelská stylistická příručka

Toto je úvodní stránka překladatelské příručky české komunity Mozilly. Pokud se chcete do překladů zapojit, přečtěte si prosím nejdříve tyto informace.

Obsah

• Stylistická příručka
• Překladatelský slovník
• Jak lokalizovat nápovědu k Firefoxu
• Jak přeložit rozhraní SUMO
• Internetová jazyková příručka
• Další pomůcky

Další rady a tipy

Kontrola pravopisu

Kontrola pravopisu není zbytečný luxus. Odstraní řadu překlepů. Ve Firefoxu můžete použít doplněk pro kontrolu překlepů a pomůže vám i služba Korektor. Hlavně u delších textů se nebojte poprosit někoho dalšího, aby po vás překlad přečetl, nebo si jej přečtěte znovu sami druhý den.

Formáty souborů

Mozilla používá nespočet formátů (např. Fluent, DTD, Properties, Gettext nebo XLIFF). Pokud budete s některým pracovat přímo, nezapomeňte si o něm předem přečíst a zeptat se na vhodný editor. Rozhodně nepoužívejte MS Word a podobné. Výsledkem by byl špatně formátovaný soubor, který není snadné upravit do správné podoby.

Kontakt

Pokud v těchto materiálech narazíte na jakoukoliv nejasnost nebo nesrovnalost, neváhejte kontaktovat český lokalizační tým.

Style Guide Czech (cs) / Překladatelská stylistická příručka

• Czech language in a nutshell
• Formality and Tone
• Natural expression
• Handling cultural references, idioms, and slang
• Units and Unit Conversion
  • Calendar view
  • Date Format
  • Time Format
  • Numerals
  • Currency
  • Units
  • Address and Postal Code Format
  • Telephone Number format
• Grammar
• Copy rules
  • Punctuation
  • Lists
  • Feature names
  • User interface elements

This style guide provides instruction for translating to the Czech locale. This style guide is to be used in coordination with the General Mozilla L10n Style Guide. Please read both before starting with any localization work on Mozilla product and project, help articles or extensions for Firefox. It will help you to avoid some common mistakes and make the translation consistent.

In addition to this style guide, please also read our glossary. Words like "kliknout" and "storno" may look trivial to you, but in fact those apply to the world of MS Windows only. In multiplatform Mozilla products we use "klepnout" and "zrušit". Some terminology may be specific directly to the product, in Firefox e.g. "záložky" ("bookmarks") or "panely" ("tabs"). Please read and use our glossary or Transvision whenever you are in doubt.

If you prefer to read the style guide in Czech, there is the L10N.cz style guide, which was created base on this one, but in may differ in less or more important parts.

Czech language in a nutshell

Czech is a West Slavic language. It’s close to Polish, Sorbian and very closely related to Slovak to the point of mutual intelligibility. Similar to other Slavic languages, nouns, verbs and adjectives are inflected. The inflection rules are complex, depending on grammatical case, gender, number, tense, person, and more.

• Czech language - Wikipedia
• Unicode CLDR - Czech Plural Rules
• Czech grammar - Wikipedia
• Localization and Plurals - MDN

Formality and Tone

The tone of Mozilla’s language should be adaptable to anyone. From new users to seasoned Mozillians, the tone should be approachable, welcoming, and inclusive. Mozilla is fun and should delight the user in expected and unexpected ways.

Especially in desktop products, prefer formal language, but stay friendly, authentic and natural. Prefer active voice over passive voice, but please note some common exceptions below. Avoid any long and complicated sentences and grammatical constructions. Clarity and meaning of every sentence has the highest priority.

In general, use the second person plural (vy - vykání) to address the user in Firefox products ("zadejte", but not "zadej"). It will not sound that strict and you will also workaround grammatical genders ("Pokud si nejste jistý/á, ..." -> "Pokud si nejste jisti, ...").

Avoid using the first person (já, mé, moje) as it can create confusion about who is being addressed. Avoid personification of the software. It’s not a live person. Instead of "Stahuji...", use passive "Stahuje se..." or "Stahování...".

In some projects (like Desktop, Android, iOS, Focus), the language will be direct as it belongs to a software string. This language should be maintained as direct, yet respectful. Avoid using imperative! In short actions and button labels use infinitive constructions ("Zobrazit", "Použít", instead of "Zobraz", "Použij"). If there is a need to ask the user to perform an action, be polite ("Vyberte (prosím)...").

Natural expression

Any translation has to obey rules of the Czech grammar. Sentences have to be both grammatically correct and also have a clear meaning. Meaning and readability is the first thing you should care about. Do not feel ashamed to read the sentence aloud or ask someone to read it for you to make sure it sounds good.

Avoid any archaisms or long and complicated sentences and constructions. Especially beware of translating the English original word by word. Do not stick to the English word order nor sentence constructions too much. Such translations are inaccurate and sound "like a robot" instead of a human. Use your own words and everyday terms to express the desired meaning instead. One of the typical examples is "Are you sure you want...?" being translated as "Jste si jisti, že chcete...?", instead of more natural "Opravdu chcete...?".

For complex sentences, read them multiple times before translating to Czech. To make the translated text sound natural, it may be necessary to adjust the number of sentences (either split them or combine) or change their order and relations. Keep the translations simple and easy to understand. Be careful about commas and semicolons too.

• Internetová jazyková příručka: Psaní čárky v souvětí
• Internetová jazyková příručka v části "Pravopis – interpunkce"
• Interpunkce na webu

Think twice when translating possessive pronouns, especially "your". You may tempt to translate "Set Firefox as your default browser" as "Nastavte si Firefox jako váš výchozí prohlížeč", however the right translation "Nastavte si Firefox jako svůj výchozí prohlížeč". Despite English does not have it, the possessive pronoun "svůj" refers to the subject and sounds much more natural in Czech. Check the language reference page and don’t be afraid to use it. ;) When translating "you"/"your" as "vy"/"váš", start the word with lowercase "v" (except where the capital letter is required by grammar, e.g. at the beginning of a sentence or label). Also keep in mind that English uses "you"/"your" more frequently than Czech does. Sometimes it sounds better if you omit the pronoun completely.

• Internetová jazyková příručka: Konkurence přivlastňovacích zájmen

A common mistake, both in translations and spoken language, is the overuse of some pronouns and conjunctions, especially "který", "pokud" and "ale". If you cannot find any better formulations, try to alternate some of the occurrences with "jenž", "avšak" or verb conditionals ("-li").

• Česká zájmena – Wikipedie

Very frequent mistake is the overuse of borrowed words and phrases. Despite some of them may be used in your day to day life, even in the related area, always use Czech equivalents if there are any. While "menu" and "level" might work for many people using computers every day, your parents will prefer Czech equivalents "nabídka" and "úroveň". Please use our glossary or Transvision to lookup Czech equivalents already in use. The only exception are branded names.

Usually it’s also better to avoid abbreviations and acronyms. In case you need to use it (e.g. because of the space limitation), please search in the existing translations first. If this is the first occurrence, lookup and use a standard one, or follow the rules from the language reference.

• Zkratky.cz - významy zkratek
• Internetová jazyková příručka: Zkratková slova

Handling cultural references, idioms, and slang

English idioms and phrases usually do not make sense in Czech translated word by word. If you see a parable or a word phrase that sound weird for you, there is a good chance it’a an idiom. There are several pages you can use to search English idioms and their meaning.

• List of Common Proverbs
• List of Common Idioms
• Cambridge English Dictionary

Once you know the idiom meaning, you can search for an equivalent in Czech, or just translate the meaning as you would say it without any parables.

• České idiomy - Wikislovník
• České fráze - Wikislovník

Units and Unit Conversion

Calendar view

In the Czech Republic, the 12-month Gregorian calendar is used with the week starting on Monday.

Date Format

Date and month, if written numerical, are single digit ordinal numbers (followed by a period with a space). In business and official correspondence double digit ordinal numbers may be used. In localization, always use the single digit form.

• Internetová jazyková příručka: Kalendářní datum a místo původu
• Date and time notation in the Czech Republic - Wikipedia

Time Format

The 24-hour cycle is used for official and exact purposes. The 12-hour cycle is also used in daily life, especially in spoken language. In localization, always use 24-hour clock.

Hours and minutes are separated by a period without any space, hours written a single digit, minutes always double digit (7.30, 18.05, 23.25). The period can be replaced by a colon. In that case hours can be written both single and double digit (7:30 or 07:30). In localization, always use the single digit form.

For time ranges, use a dash without space (10-13 h, 12.00-12.45).

• Internetová jazyková příručka: Časové údaje
• Date and time notation in the Czech Republic - Wikipedia

Numerals

Numerals can become a pretty hard nut to crack, especially in case of words composed from digits and words. As a localizer, you should get familiar with the correct grammar for numerals below (what’s the difference between "12m" and "12 m", or how to correctly write "dvaačtyřicetiletý" with digits).

• Internetová jazyková příručka: Znaky, čísla a číslice
• Internetová jazyková příručka: Tvoření a psaní výrazů složených z číslic a slov
• České číslovky – Wikipedie

Currency

The currency of the Czech Republic is the Czech koruna (CZK). The monetary signs are Kč or ,- separated by a space from the amount (50 Kč). If used as a adjective (e.g. a fifty-crown coin), the symbol is without any space (50Kč mince).

• Internetová jazyková příručka: Peněžní částky, značky měn
• Internetová jazyková příručka: Tvoření a psaní výrazů složených z číslic a slov

Units

In the Czech Republic metric system (kilograms, meters, ...) is used.

Address and Postal Code Format

[addressee]
[street name][building and suite numbers]
[postal code][city/post name]

Vážená paní
Jarmila Novotná
Pod Mlýnem 4
463 41 Dlouhý Most

• Internetová jazyková příručka: Adresy

Telephone Number format

Phone numbers in the Czech Republic consist of 9 digits, usually separated by triplets. Usually the phone number also have the international code (+420 or less frequently 00420) in front.

+420 ### ### ###

Grammar

Any translation has to obey rules of the Czech grammar. Sentences have to be both grammatically correct and also have a clear meaning. Avoid any archaisms or long and complicated sentences and constructions. When using any, make sure the punctuation is correct. Punctuation saves lives.

• Internetová jazyková příručka: Psaní čárky v souvětí
• Internetová jazyková příručka: Pravopis – interpunkce
• Interpunkce na webu

Copy rules

In full sentences and texts on websites or support articles, always follow the grammatical rules for capitalization.

• Internetová jazyková příručka: Psaní velkých písmen – obecné poučení
• Internetová jazyková příručka: Pravopis – velká písmena

Punctuation

Note, include the terminal punctuation in hyperlink if the entire text in the UI is linked. Do not include the terminal punctuation in the hyperlink if the link is within running text or only part of the sentence is linked.

In texts, do not forget a space after a period at the end of a sentence. Spaces need to be also written after (but not before) colons or semicolons. Text inside brackets is not separated by spaces from them, but the correct placement of spaces is right before the opening and after the closing bracket only.

• Internetová jazyková příručka: Tečka
• Internetová jazyková příručka: Dvojtečka
• Internetová jazyková příručka: Závorky
• Internetová jazyková příručka: Lomítko

For quotes use the Czech double quotation marks („ and “). On the Czech keyboard, you can write them as Alt + 0132 and Alt + 0147 respectively. The corresponding HTML entities are „ and “. For code snippets or API or function name references use quotation marks or apostrophes (" or '). These you can usually copy from the original English text.

• Internetová jazyková příručka: Uvozovky

Lists

Lists in Czech do not have a strict rules to obey. However there are good practices to follow, all mentioned in the language reference page.

• Internetová jazyková příručka: Psaní výčtů

Feature names

Title case does not look natural for the Czech language. Even for product features, use lowercase, but obey the general grammatical rules. E.g. "With Tracking protection..." would be translated as "S ochranou proti sledování...".

If you want to really emphasize the importance of the feature, you can use title case for the first word of its name in nominative and introduce it by a general word "funkce". The previous sentence would now look like "S funkcí Ochrana proti sledování...". But even here more natural wording "S funkcí ochrany proti sledování..." is preferred, with the feature name all in lowercase.

User interface elements

• Titles should be brief and precise. Unless necessary, it shouldn’t be a whole sentence. Capitalize the first letter of the first word only.
• Window titles should be short and use infinitive form, e.g. "Uložit soubor".
• In buttons capitalize the first letter of the first word in the label only. Limit the whole text to one or two words. Use verbs in infinitive form that precisely describe the button’s action result. It’s way better to translate "Install" button label as "Nainstalovat" than "Instalovat". Most of them will be probably covered in our glossary.
• Checkboxes and radio buttons capitalize the first letter of the first word and use infinitive form. Make sure that the translations of elements in the same group or section are consistent and sound natural as a list of alternative or complementary choices.
• In select options list capitalize the first letter of the first word, unless the selector makes a sentence together with the corresponding label. In that case make sure all options make a correct sentence with the label. Try to keep all the options about the same length and preferably short.
• Tooltips serve the purpose of a short help and appear when mouse is hovered over an UI element. Use active voice with the element as unexpressed subject, e.g. "Zobrazí historii", "Uloží soubor", "Otevře nabídku".
• Accesskeys, sometime also called accelerators, are keys to access specific UI elements using your keyboard only. Combined with screen readers, accesskeys improve the accessibility for visually impaired users, or used standalone they speedup the UI navigation. In the UI you can often determine them as underscored letters. When localizing accesskeys you have to make sure the letter is on the Czech keyboard and users can press it with the Alt key at the same time. The rule of thumb is to only use letters without diacritics. To make the accesskeys look and work the best, use letters contained in the corresponding label and if possible unique in the application menu or dialog. If it fulfills the mentioned rules, using the same accesskey as in English is a small plus.
• Commandkeys are similar to accesskeys, but they work as regular keyboard shortcuts (e.g. Ctrl+S for save or Ctrl+Q to quit the application). Always keep the same commandkey as in English, unless the key is not available on the standard Czech keyboard. See the Shortcuts and Accesskeys section in the General Mozilla L10n Style Guide for more information about both accesskeys and commandkeys.

Překladatelský slovník

• Části aplikací
• Doplňky
• Prvky uživatelského rozhraní
  • Nástrojové lišty
  • Ostatní lišty
  • Prvky lišty navigace
  • Prvky lišty pošty
  • Dialogy a upozornění
  • Obecné prvky uživatelského rozhraní
• Nabídky
  • Položky hlavní nabídky
  • Položky nabídky Soubor
  • Položky nabídky Úpravy
  • Položky nabídky Nápověda
  • Položky místní nabídky
• Akce uživatele
  • Akce myší
  • Obecné akce
• Obecné výrazy
• Odborné výrazy
• Prohlížeč
• E-mailový klient

Pokud překládáte aplikace Mozilly, či některá jejich rozšíření, je nutné, aby se základní termíny překládaly stejně. Uživatelé pak nejsou mateni různými výrazy, které ve skutečnosti znamenají totéž, a překlad je celkově konzistentní.

V níže uvedených tabulkách naleznete základní výrazy, které se v aplikacích často používají, a jejich české ekvivalenty. Další výrazy obsahují slovníky L10N.cz nebo online nástroj Transvision. Pokud máte pocit, že některý běžně používaný výraz ve slovníku chybí, napište nám prosím.

Části aplikací

Doplňky

Prvky uživatelského rozhraní

Nástrojové lišty

Ostatní lišty

Prvky lišty navigace

Prvky lišty pošty

Dialogy a upozornění

Obecné prvky uživatelského rozhraní

Další prvky viz Slovník vizuálních prvků.

Nabídky

Položky hlavní nabídky

Položky nabídky Soubor

Položky nabídky Úpravy

Položky nabídky Nápověda

Položky místní nabídky

Akce uživatele

Akce myší

Obecné akce

Obecné výrazy

Odborné výrazy

Prohlížeč

E-mailový klient

Styleguide: Dutch (nl)

Dit document is een gedeeltelijke kopie van de pagina op www.mozilla-nl.org. Aan een echte stijlgids wordt nog gewerkt, zij het met lage prioriteit.

Algemene regels

• Spreek de gebruiker aan met u, niet je.
• Helpfiles auteursrecht: Auteursrecht © 2003-20xx Medewerkers van het Mozilla Help Viewer Project. (Gebruik het actuele jaar.)
• Aangezien we als Mozilla-NL vaak dezelfde richtlijnen volgen als de vertaling van KDE, slaat de uitleg in de KDE-vertaalgids en de bijbehorende woordenlijst ook op de vertaling van Mozilla. De woordenlijst op deze pagina heeft wel voorrang.
• Voor andere zaken waarover wordt getwijfeld, kunnen de woorden worden opgezocht in het Vrijschrift-woordenboek of in de lijst met online woordenlijsten die GNOME-NL heeft opgesteld.

Aanhalingstekens en apostroffen

In de Nederlandse vertaling gebruiken we zgn. ‘gekrulde’ aanhalingstekens en apostroffen. Dit omdat deze typografisch beter staan, en de Unicode-standaard ook aanraadt in plaats van de ' een ’ te gebruiken voor apostroffen. Een overzicht van de tekens:

Je kunt de tekens zelf gewoon in de Unicode-gecodeerde bestanden gebruiken. Mozilla gebruikt - tegen de richtlijnen van Sun in - voor bijna alle bestanden utf-8. Voor uitzonderingen, zie MDN.

Als je geen qwerty-internationaal gebruikt, zijn deze tekens eenvoudig in de ‘character map’ (Start / Programma’s / Bureau-accessoires / Systeemwerkset / Speciale tekens) te vinden. Kies daarvoor ‘Geavanceerde weergave’, ‘Groeperen op: Unicode-subbereik’, ‘Algemene interpunctie’, en daar staan ze dan tussen.

Voor Linux is er het programma ‘gucharmap’, dat net zo werkt.

Waarschuwing: gebruik nooit en te nimmer de accenttekens (U+0060) en (U+00B4). Dit zijn geen aanhalingstekens; ze hebben een ander doel en ze zien er anders uit. Het gebruik van deze tekens veroorzaakt bijvoorbeeld ongewenste extra spatiëring.

Handleiding voor het vertalen van Firefox-teksten

Deze handleiding is bedoeld om het schrijven en vertalen van teksten te vergemakkelijken en optimale voorbereiding en consistentie te bevorderen. De handleiding wordt voortdurend bijgewerkt. Ons merk ontwikkelt zich en we zullen dit document aan deze ontwikkelingen blijven aanpassen.

Waarom is deze handleiding belangrijk voor het vertalen van Firefox-teksten?

Deze handleiding helpt je om Firefox als merk beter te begrijpen, zodat je beter in staat bent om de teksten naar je eigen taal te vertalen. De handleiding bevat bovendien vaste, bedrijfsspecifieke termen en spellingaanwijzingen om het vertaalproces te vergemakkelijken.

Het is niet de bedoeling dat onze teksten een-op-een worden vertaald. Ze moeten een afspiegeling zijn van de persoonlijkheid en de toon van het merk en moeten worden aangepast aan de doelcultuur en de doeltaal. De emotionele en symbolische betekenis van de brontekst moet worden aangepast voor de doeltaal.

Over Firefox — Wie zijn wij?

Firefox is meer dan alleen een browser. Firefox is een uitdagend merk dat de status quo ter discussie stelt en opkomt voor de online rechten van gebruikers.

De rechten en behoeften van onze gebruikers staan bij ons voorop in alles wat we doen. En als techbedrijf vinden we mensen belangrijker dan winst.

Firefox als merk is een combinatie van de ethos van Firefox en onze verwante producten.

(Mozilla is de non-profitorganisatie achter Firefox.)

Merkbelofte:

Firefox zet zich voor je in

Waar we voor strijden:

Firefox zet zich voor onze gebruikers in door producten te creëren die mensen controle geven over hun online leven.

Producten:

• Firefox Quantum (desktopbrowser)
• Firefox Mobile (voor iOS en Android)
• Firefox Monitor
• Pocket
• Mozilla VPN
• Firefox Private Network (FPN)
• Firefox Relay

Persoonlijkheid en toon

Wie is onze doelgroep?

We omschrijven onze doelgroep als Bewuste beslissers. Dit zijn mensen die bewuste keuzes (willen) maken, zowel online als offline.

Bewuste beslissers:

• ontwikkelen zorgvuldig en bewust voorkeuren en baseren hier hun keuzes als consument op;
• streven ernaar hun handelen af te stemmen op hun waarden en idealen;
• zijn veeleisende klanten;
• doen vaak hun eigen onderzoek om alle mogelijkheden volledig te begrijpen.

De Bewuste beslissers zijn onder te verdelen in twee groepen die we specifiek willen aanspreken. Privacybeschermers en Avontuurlijke trendsetters.

Privacybeschermers:

• zijn waarschijnlijk al gebruikers van Firefox;
• vinden privacy belangrijk en zijn bereid te betalen voor meer digitale veiligheid;
• vinden dat het internet de verantwoordelijkheid heeft om zijn gebruikers te beschermen.

Avontuurlijke trendsetters:

• zijn trendvolgers en trendsetters;
• willen dat hun vrienden en volgers zien dat ze goede keuzes maken;
• streven ernaar hun community te beïnvloeden om dezelfde goed doordachte keuzes te maken.

Onze merkkenmerken en de merkpersoonlijkheid van Firefox

De merkpersoonlijkheid van Firefox wordt bepaald door de interactie van deze kenmerken. Afhankelijk van de context kan het ene kenmerk meer of minder prominent zijn dan een andere kenmerk.

Toon

Onze toon en stijl is:

Woordenlijst / Veel voorkomende termen (WORDT VOORTDUREND BIJGEWERKT)

Bij onduidelijkheden kun je ook gebruikmaken van de Transvision-tool. Deze tool levert vaak oudere versies van vertalingen op (vaak met een formele aanspreekvorm), dus gebruik de tool alleen als richtlijn.

Style Guide Esperanto (eo)

Ĝeneralaj reguloj por tradukoj

Elektado de vortoj

Bonvolu kontroli kiel oni tradukis antaŭe similajn frazojn (langeto Machinery en Pontoon). Vi povas uzi ankaŭ Transvision por tio. Manko da kohereco povas esti kialo ne akcepti (aŭ devi modifi) sugestitan tradukon, eĉ se la traduko estis bona. Ekzemple, kaj "forviŝi" kaj "forigi" povas esti taŭgaj tradukoj por "delete", sed ni uzas "forigi" en Firefox.

Tamen, oni povas ĉiam pridiskuti la elekton de kelkaj vortoj, eĉ se ili estas ofte kaj/aŭ delonge uzataj. Tio okazis jam plurfoje. Du menciindaj okazoj: la ŝanĝo de "paĝosigno" al "legosigno" kaj la ŝanĝo de "retesplorilo" al "retumilo". Do, se vi opinias ke iu termino estas ŝanĝenda, unue oni tion diskutu kaj poste, se estas konsento, oni tion amase ŝanĝos.

Bonvolu uzi nur Fundamentajn, oficialajn kaj Zamenhofajn radikojn, se tio eblas. Novradikoj kaj novaj elementoj estas evitindaj. La kategorio de radiko estas kutime kontrolebla en iu ajn vortaro esperantlingva.

Terminaro

Kvankam ankoraŭ ne estas aparta terminaro, vi povas kontroli tradukojn serĉante la vorton en Transvision (Pli da informo ĉe Rimedoj).

Gramatiko kaj vortaro

Nia norma gramatiko estas PMEG kaj la norma vortaro estas PIV - Plena Ilustrita Vortaro de Esperanto. Aliaj estas uzeblaj, kompreneble, sed okaze de dubo, la ĉi supraj estos decidaj.

verboformoj

La -u formon oni nur uzas kiam la programo petas ion al la uzanto. Ekzemple (re)tajpu vian pasvorton aŭ elektu pli etan valoron. En ĉiuj aliaj okazoj oni uzas ĉu la (-ad)-o formon, ĉu la -i formon. Kiam kaj -o kaj -ad-o eblas (ekzemple por import-) oni uzu la pli mallongan, kio cetere povas esti bona afero por la poŝaparataj produktoj, kie loko estas elĉerpebla rimedo.

sensubjektaj verboj

En la angla aperas tekstoj kiel "Loading..." aŭ "Reading files...", kie la subjekto estas subkomprenata (kutime temas pri la retumilo). Ni tamen bezonas havi subjekton. Do, depende de la frazo oni povas uzi la -ad- formon, por indiki daŭran agon, aŭ tripunkton, aŭ igi la frazon pasiva.

vortordo

La vortordo ne havas limigojn, krom tio ke ni preferas tiu ĉi anstataŭ ĉi tiu. Oni tamen klopodu resti kohera kun la vortordo de subjekto, objekto, verbo, ktp. en la cetero de la tradukunuo, kiun oni tradukas (retpaĝo, fenestro, panelo, ktp.)

adjektivo aŭ aparteno

Oni povas klarigi dubon inter adjektivo aŭ aparteno per la jena ekzemplo:

miŝmiŝ estas kata nomo (sed eble neniu kato tiel nomiĝas)

miŝmiŝ estas nomo de kato (do, krom esti taŭge kata, iu kato fakte tiel nomiĝas)

uskleco (majuskloj kaj minuskloj)

Majuskle oni nur skribas la komencon de la frazo kaj proprajn nomojn. Ĉiujn aliajn vortojn oni skribas minuskle, krom kiam ili estas mencio al butono aŭ menuero, kiujn ni konsideras propran nomon en tiu kunteksto.

netradukeblaj vortoj

En tiuj okazoj, oni klare montru ke tiu vorto estas alilingva.

Tie ĉi, Ping estas angla vorto kiun ni ne opiniis tradukebla/tradukinda.

Ordonklavoj

Ordonklavojn (command keys) ni ne tradukas. Tiuj estas la klavoj, kiujn oni premas kune kun la stirklavo. Ili restas same al tiuj en la angla versio (ekzemple, stir+f por serĉi).

Alirklavoj

Alirklavojn (access keys) ne forgesu ŝanĝi! Alirklavo estas la klavo kiun oni povas premi por iri rekte al menuero aŭ butono. Estas grava afero el aspekta kaj ankaŭ el alirebleca vidpunkto, ĉar tio permesas rapidan aliron al menuero aŭ butono. Tial oni klopodu havi malsamajn alirklavojn por ĉiu teksto en unu fenestro.

Rimedoj

Iloj de Mozilla

Pontoon estas la oficiala reta tradukilo de produktoj de Mozilla. Dum tradukado ĝi permesas vidi la tradukojn en aliaj lingvoj (vi povas agordi kiujn vi volas vidi unue).

Transvision permesas serĉi tradukojn en ĉiuj produktoj kaj lingvoj de Mozilla. En tiu sistemo eblas ankaŭ raporti cimojn kaj vidi kion la aliaj lingvojn tradukis.

Lingvaj

PIV - Plena Ilustrita Vortaro de Esperanto

Revo - Reta vortaro

Style Guide Finnish (fi)

Mozillan suomen kielen lokalisoinnin tyyliopas

Intro

Tyyliopas vastaa muutamiin yleisiin tyylikysymyksiin Mozilla-tuotteiden ja Mozilla-sivustojen kääntämisessä.

Esimerkkejä kansainvälisistä tyylioppaista:

• https://help.apple.com/applestyleguide/
• https://www.microsoft.com/en-us/language/StyleGuides?rtc=1

Tyyli

Kaiken kirjoitetun pitäisi noudattaa kirjakielen sääntöjä. Markkinointiviestit voivat olla tyyliltään vapaampia, mutta puhekieltä ei pitäisi käyttää niissäkään.

Käännösten tavoite on olla niin selkeitä, että “mummosikin ymmärtää”. Luonnollisesti tämä riippuu mummosta, mutta yksinkertainen tapa sanoa asia on aina ylivertainen verrattuna teknisesti tarkkaan versioon. On hyvä pitää mielessä, että päivittäisten suomenkielisen Firefoxin käyttäjien määrä on puolen miljoonan paremmalla puolella, joten käyttäjät ovat aivan tavallisia ihmisiä.

Sävyltään tekstin pitäisi seurata alkuperäistä englanninkielistä tekstiä, mutta suomen kieli on luonnostaan rauhallisempaa kuin amerikanenglanti, joka pitää ottaa huomioon erityisesti markkinointiviestintää käännettäessä.

Ohjelmistoja kääntäessä ei yleensä käytetä pronomineja aktiivisesti. Ei siis käännetä “You can click…” “Sinä voit napsauttaa…”, vaan muutetaan ohjeistukset yleensä passiivisiksi “Napsauttamalla…”. Vastaavasti ei yleensä käytetä muotoja minun/sinun käännöksissä (vaan esim. Oma).

Ohjelmia, tavaramerkkejä tai palvelujen nimiä ei yleensä käännetä vaan lisätään tarkentava kuvaus nimen jälkeen, esimerkiksi Firefox Sync -palvelu. Mozillan käännöstiedostoissa tällaiset tuotenimet ovat usein muuttujina, jolloin pitää olla tarkkana että pääte tulee oikein. Kansainvälinen ohjeistus: https://www.mozilla.org/en-US/styleguide/identity/firefox/branding/.

Oikeinkirjoitus- ja kielioppiohjeistus

TBD? Many languages have national or international standards that define spelling and grammar rules. When defining these rules for your community, make reference to those standards wherever possible. Do you have automated tests for spell checking and grammar? List those tools and dictionaries here and how regularly they should be used.

• Lyhenteet: http://www.kielitoimistonohjepankki.fi/haku/lyhenteet/ohje/257
• Pilkkusäännöissä perusteet pitää olla kunnossa: http://www.kielitoimistonohjepankki.fi/haku/pilkku/ohje/86
• Väliviivat ja -merkit: http://www.kielitoimistonohjepankki.fi/haku/v%C3%A4limerkki/ohje/133](http://www.kielitoimistonohjepankki.fi/haku/v%C3%A4limerkki/ohje/133)

Yksiköt

Yksiköissä käytetään SI-yksiköitä ja suomen kielen merkintätapaa niille (https://fi.wikipedia.org/wiki/Kansainv%C3%A4linen_yksikk%C3%B6j%C3%A4rjestelm%C3%A4#Kirjoituss.C3.A4.C3.A4nn.C3.B6t).

Tallennuskapasiteetin yksiköinä käytetään lähdetekstin mukaista käytäntöä. Kilotavut, megatavut, gigatavut lyhennetään kt, Mt, Gt jne.

Päiväys & kalenteri

Päiväykset kielitoimiston ohjeistusten mukaisesti: http://www.kielitoimistonohjepankki.fi/haku/p%C3%A4iv%C3%A4ys/ohje/53.

Termistö

Termistöä löytyy täältä…

cancel -> peruuta

lista -> lista tai luettelo, usein lista

Uusien vaikeiden termien kääntämistä kannattaa lähestyä hakemalla olemassa olevia käännöksiä tai yrittämällä ymmärtää, mitä ominaisuus tarkoittaa.

Käyttöliittymäelementtikohtaisia ohjeita

Pikanäppäimet

Pikanäppäimille (access keys) ei ole ohjeistusta (TBD). Pikanäppäimet yleensä määritelty kontekstissa ensimmäiseksi vapaaksi pikanäppäin-kirjaimeksi merkkijonossa.

Muut käyttöliittymäelementtikohtaiset ohjeistukset

• Painikkeet: Ensimmäinen sana voi olla isolla. Verbien käyttö suositeltua, mutta voidaan unohtaa jos tila ei muuten riitä ja ymmärrettävyys ei kärsi.
• Arvolistat: Seuraa lähdetekstin versaalit/gemenat -muotoa, mutta vain ensimmäinen sana (ja erisnimet) isolla.
• Ellipsis: Kolme pistettä eli ellipsis-merkkiä tulee käyttää lähdetekstin mukaisesti.

Yleiset ohjeet

Tärkeimmät mielessä pidettävät asiat tehdessä käännöksiä ovat:

• Ymmärrettävyys, selkeys
• Johdonmukaisuus

Ymmärrettävyyden kannalta keskeistä on, että kääntäjä ymmärtää toiminnon ja mitä toiminto tarkoittaa. Mozilla tarjoaa tähän joitain apuja, mutta paras tapa on usein käyttää kehitysversioita ohjelmistosta, jotta näkee toiminnot käytännössä.

Johdonmukaisuus voi rikkoutua ohjelman sisällä kun kääntäjä unohtaa, mitä termiä tai tyyliä on käyttänyt aikaisemmin tai ohjeistuksen ja ohjelman välillä jos ohjeistuksen kirjoittaja ei ole selvillä ohjelmassa olevasta käännöksestä.

Johdonmukaisuuden tärkein tekijä on jatkaa projektin parissa pidempään ja oppia tekemällä. Toinen loistava työkalu johdonmukaisuuteen on käyttää http://transvision.mozfr.org/ -palvelua selaamaan olemassa olevia käännöksiä ja viimeisenä luonnollisesti kommunikointi kääntäjien kesken.

Style Guide French (fr)

Read the style guide here

French Localization Guide

Ce document est à l’usage de toutes les personnes amenées à écrire pour Firefox en français. Il a pour objectif d’uniformiser le ton et la voix de la marque sur toutes les plateformes et à travers le monde.

Pourquoi a-t-on besoin d’un tel guide pour localiser le contenu ?

Firefox parle d’une même voix dans le monde entier, mais nous voulons éviter de traduire notre contenu de manière littérale. Il est important de maintenir l’image de la marque et l’intention originale du message, en prenant soin d’adapter le langage aux spécificités locales.

En somme, ce guide est écrit pour :

• Développer un ton qui reflète l’image de la marque et qui convient à notre public
• Uniformiser la traduction des termes techniques et/ou spécifiques à la marque

Le lexique en fin de document permet d’assurer une certaine cohérence dans la terminologie que nous employons.

Les consignes de ce document ne sont pas gravées dans la roche. Notre marque évolue, nous actualisons donc le document lorsque c’est nécessaire.

À propos de Firefox – Qui sommes-nous ?

Firefox, c’est bien plus qu’un navigateur. C’est une marque reconnue à travers le monde, qui remet en question le statu quo et qui lutte pour les droits des internautes.

Nous plaçons les utilisateurs et utilisatrices au centre de tout ce que nous créons et décidons.

La marque Firefox représente une philosophie qui place les internautes avant les bénéfices, et ce dans chacun des produits de sa gamme.

Mozilla est l’organisation à but non lucratif à l’origine de Firefox.

La promesse de la marque :

Firefox se bat pour vous

Ce pour quoi nous nous battons :

Firefox se bat pour défendre les internautes en leur proposant des produits qui leur permettent de prendre le contrôle de leur vie en ligne.

L’objectif de la marque :

Expliquer aux internautes que Firefox est la marque qui tient leurs intérêts à cœur et qu’ils ont le contrôle et sont en sécurité quand ils utilisent les outils Firefox.

Les produits Firefox :

• Firefox Quantum (navigateur de bureau)
• Firefox Mobile (sur iOS et Android)
• Firefox Monitor
• Pocket
• Firefox Reality (navigateur web immersif)

Personnalité et ton de la marque

À qui s’adresse-t-on ?

Nous ciblons les personnes qui font des choix réfléchis, c’est à dire qui ne prennent pas de décisions au hasard mais qui choisissent consciencieusement, autant en ligne que hors ligne.

Choisir consciencieusement signifie :

• Développer des préférences et prendre des décisions de consommations réfléchies.
• S’efforcer d’agir selon ses valeurs et ses idéaux.
• Faire preuve d’exigence et ne pas se satisfaire du minimum.
• Effectuer son propre travail de recherche afin de comprendre toutes les options qu’on a à sa disposition.

Personnalité de la marque Firefox

La marque repose sur quatre piliers, véritables fondations de tout ce que nous faisons et de tout ce que nous écrivons, aussi bien en anglais qu’en français.

Nous sommes dogmatiques, mais ouverts. Nous sommes radicalement bienveillants. La personnalité de la marque tient sa richesse de ses traits de caractère opposés en apparence, mais essentiellement complémentaires chez Firefox.

Ton de la marque

2ᵉ personne du pluriel et forme impersonnelle

Il est recommandé d’utiliser, selon le contexte, soit la deuxième personne du pluriel, soit la forme impersonnelle (« on »). Le tutoiement est à proscrire, sauf lorsque le contexte le requiert (citations, expressions, etc.)

Écriture inclusive et emploi du masculin et féminin

Nous prenons soin de n’exclure personne et de nous adresser au public le plus large possible et évitons autant que possible les termes et formules genrés. L’exercice relevant parfois de l’acrobatie, il est important de se fier à son bon sens afin d’éviter les phrases et formules alambiquées qui alourdissent le texte et peuvent distraire le lectorat du message que nous souhaitons faire passer.

Cette liste non-exhaustive de consignes s’applique à notre contenu marketing.

Privilégier les formules épicènes (invariables en genre) ou les formules englobantes (mots génériques pour désigner un groupe de personnes) :

• Mots épicènes : internaute, élève, adulte, analyste, etc.
• Formules englobantes : l’équipe de développement, les personnes malvoyantes, tout le monde, etc.

Dans la mesure du possible éviter la voix passive afin de ne pas avoir à accorder un participe passé.

• Exemples :
  👎 Vous êtes suivi(e) par des traqueurs partout sur le Web.
  👍 Des traqueurs vous suivent partout sur le Web.

Lorsqu’il n’y a pas de contraintes de limite du nombre de caractères, la double flexion peut être utilisée, avec l’accord au masculin pluriel.

• Exemples :
  👎 Les étudiants et les étudiantes sont fatigué·es
  👍 Les étudiants et les étudiantes sont fatigués.

Dans les phrases courtes et percutantes (slogans, balises h1), utiliser le masculin pluriel en guise de neutre.

• Exemples :
  👎 Êtes-vous prêt à franchir le pas ?
  👎 Êtes-vous prêt·e à franchir le pas ?
  👍 Êtes-vous prêts à franchir le pas ?

Quand on parle de nous-mêmes, on utilise le masculin pluriel

• Exemples :
  👍 Chez Firefox, nous sommes convaincus que vos données vous appartiennent.

Donner plus de visibilité au féminin, notamment en l’utilisant dans des exemples et démonstrations de cas particuliers, ainsi qu’en féminisant les fonctions.

• Exemples :
  👍 Une utilisatrice lambda doit s’inquiéter de la manière dont ses données sont traitées.
  👍 La présidente de l’Estonie a rencontré la première ministre de l’Islande.

N’utiliser le point-milieu qu’en dernier recours, de préférence uniquement au singulier et lorsque la terminaison du féminin peut s’apposer au masculin sans fléchir le radical.

• Exemples :
  👎 Les instituteur·trice·s se sont mis·e·s d’accord :
  👍 C’est un·e élève discipliné·e.
  👍 Nous recherchons un·e excellent·e informaticien·ne.

Règles typographiques

Se référer au guide stylistique pour la traduction pour les règles concernant la typographie en français.

Titres d’œuvres

Les titres d’œuvres, de publications, d’émissions de télé ou de radio, etc. doivent être placés en italique, sans guillemets. On parlera ainsi d’un article du Monde, ou de 1984, l’œuvre prophétique d’Orwell.

Anglicismes

Nous parlons et écrivons comme notre public parle et écrit. Nous défendons un usage libre de la langue française et ne forçons personne à franciser les mots empruntés à l’anglais. Nous recommandons l’utilisation du terme le plus couramment employé dans la langue de tous les jours. On préférera donc les termes e-mail (avec le trait d’union), bug, chat ou newsletter à la place de courriel, bogue, clavardage et liste de diffusion.

Les mots empruntés à l’anglais (ainsi qu’à d’autres langues) et non adoptés par l’usage sont mis en italique.

Exemples :

• Les entreprises sont appelées à mettre en place les bonnes pratiques de lean data.
• la NSA a publié un document informant ses employés des dangers du juice jacking.

Calls to action (CTA)

Le verbe dans les CTA (boutons d’appel à l’action en bon français) doit préférablement être à l’infinitif.

Exemples :

• Télécharger Firefox plutôt que Téléchargez Firefox, ou encore Lire l’article plutôt que Lisez l’article.

Expressions et métaphores Dans la traduction, toujours s’assurer que les expressions employées en français sont idiomatiques. Si ce n’est pas le cas, chercher une expression équivalente. Les noms de marques tierces doivent être laissés tels quels. Dans le cas d’une référence culturelle inadaptée à un public francophone, ne pas hésiter à trouver une marque française équivalente.

Textes optimisés pour le référencement (SEO)

• Comme tout ce que nous écrivons, les textes SEO doivent être localisés de manière à ce qu’ils offrent de la valeur aux lecteurs. Il faut s’assurer que les textes SEO sont aussi intéressants et pertinents que les articles de nos blogs.
• Les titres doivent être aussi précis que possible et doivent adresser le sujet de l’article en question, pas seulement le thème général (par exemple, un article sur le respect de la vie privée ne doit pas s’intituler : Tout ce qu’il faut savoir sur le respect de la vie privée).

Articles sur le blog

• Le titre de l’article doit être aussi précis que possible et doit préférablement tenir sur une seule ligne.
• Dans la mesure du possible, la première phrase doit apparaître intégralement dans l’aperçu de l’article afin que les lecteurs sachent à quoi s’attendre avant de cliquer.
• Ne pas hésiter à diviser l’article en paragraphes et à utiliser des sous-titres afin de le rendre plus facile à lire.

Lexique

Expressions fréquentes dans l’univers Firefox

Les expressions suivantes reviennent fréquemment dans nos articles et il est important de toujours utiliser la même traduction pour des raisons de cohérence.

L’outil de recherche Transvision est une excellente ressource qui permet de voir certaines expressions et tournures de phrase dans différents contextes et leur traduction en français.

Afin d’éviter la confusion, les termes suivants doivent être traduits comme indiqué ci-dessous.

Expressions spécifiques à la marque :

Quelques règles générales

Mozilla Tone of Voice & Localisation Guide (French)

Pourquoi ce guide est-il important pour la localisation de nos textes ?

Nos textes ne doivent pas être traduits mot à mot, mais doivent refléter la personnalité et la tonalité de notre marque et être optimisés en fonction du contexte culturel et linguistique. L’intention émotionnelle du texte source doit être adaptée.

Why is this guide important for the localization of our copy?

Our copy should not only be translated one-to-one, but should reflect our brand personality and tonality and be optimized for the cultural and linguistic background. The emotional intention of the source text should be adapted.

Ton/Tonality

Notre langage est/our language is:

Glossaire/Glossary

Les termes que nous utilisons systématiquement dans nos produits se trouvent dans notre glossaire. Cette liste comprend de nombreuses caractéristiques des produits et termes techniques. N’oubliez pas de la consulter lorsque vous écrivez sur nos produits.

Terms we consistently use across our products can be found in our glossary. This list includes many tour product features and technical terms. Pls make sure to check back while writing for our products. Full Glossary for all products

Expressions spécifiques à la marque/Company specific language:

Règles générales/general rules (dates, times, grammar)

Règles typographiques / Typography rules

Se référer au guide stylistique pour la traduction pour les règles concernant la typographie en français.

Écriture inclusive et emploi du masculin et du féminin

Nous prenons soin de n’exclure personne et de nous adresser au public le plus large possible et évitons autant que possible les termes et formules genrés. L’exercice relevant parfois de l’acrobatie, il est important de se fier à son bon sens afin d’éviter les phrases et formules alambiquées qui alourdissent le texte et peuvent distraire le lectorat du message que nous souhaitons faire passer.

Cette liste non exhaustive de consignes s’applique à notre contenu marketing.

Privilégier les formules épicènes (invariables en genre) ou les formules englobantes (mots génériques pour désigner un groupe de personnes) :

• Mots épicènes : internaute, élève, adulte, analyste, etc.
• Formules englobantes : l’équipe de développement, les personnes malvoyantes, tout le monde, etc.

Dans la mesure du possible éviter la voix passive afin de ne pas avoir à accorder un participe passé.

• Exemples :
  ❌ Vous êtes suivi(e) par des traqueurs partout sur le Web.
  ✅ Des traqueurs vous suivent partout sur le Web.

Lorsqu’il n’y a pas de contraintes de limite du nombre de caractères, la double flexion peut être utilisée, avec l’accord au masculin pluriel.

• Exemples :
  ❌ Les étudiants et les étudiantes sont fatigué·es
  ✅ Les étudiants et les étudiantes sont fatigués.

Dans les phrases courtes et percutantes (slogans, balises h1), utiliser le masculin pluriel en guise de neutre.

• Exemples :
  ❌ Êtes-vous prêt à franchir le pas ?
  ❌ Êtes-vous prêt·e à franchir le pas ?
  ✅ Êtes-vous prêts à franchir le pas ?
  

Quand on parle de nous-mêmes, on utilise le masculin pluriel.

• Exemple :
  ✅ Chez Firefox, nous sommes convaincus que vos données vous appartiennent.

Donner plus de visibilité au féminin, notamment en l’utilisant dans des exemples et démonstrations de cas particuliers, ainsi qu’en féminisant les fonctions.

• Exemple :
  ✅ Une utilisatrice lambda doit s’inquiéter de la manière dont ses données sont traitées.
  ✅ La présidente de l’Estonie a rencontré la Première ministre de l’Islande.

N’utiliser le point-milieu qu’en dernier recours, de préférence uniquement au singulier et lorsque la terminaison du féminin peut s’apposer au masculin sans fléchir le radical.

• Exemples :
  ❌ Les instituteur·trice·s se sont mis·e·s d’accord :
  ✅ C’est un·e élève discipliné·e.
  ✅ Nous recherchons un·e excellent·e informaticien·ne.

En cas de doute sur l’utilisation d’un mot en écriture inclusive, on peut se référer à : https://eninclusif.fr/.

Personnalité de la marque Mozilla - pour contexte / Mozilla Brand Personality - for context

Style Guide German (de)

Wenn Sie bei der Übersetzung mitmachen wollen, so wenden Sie sich bitte an die Person aus dieser Liste hier, welche für Ihr Interessengebiet zuständig ist.

Was sollte bei der Übersetzung beachtet werden?

Rechtschreibung/Grammatik

Da als Bezeichnung meistens nur einzelne Stichwörter verwendet werden, sollte vor allem auf Tippfehler und Buchstabendreher geachtet werden. In Beschreibungen, die möglichst einen vollständigen Satz ergeben sollten, ist weiterhin noch auf Rechtschreibung/Grammatik im Allgemeinen zu achten. Die meistverbreiteten Fehler sind der falsche Einsatz von Leerzeichen/Bindestrichen sowie Groß- und Kleinschreibung.

Umlaute und Sonderzeichen sollen auf alle Fälle korrekt eingesetzt und dargestellt werden. ae, ue, oe, ss etc. sind keine Alternative.

Terminologie

Wir sind bemüht, zur Vereinheitlichung und für ein homogenes Erscheinungsbild innerhalb des offiziellen Rahmens der deutschsprachigen Mozilla-Produkte zu arbeiten. Weiterhin lassen sich auch Begriffe aus schon geprüften und veröffentlichten Erweiterungen nutzen (falls die Anwendungen keine Hilfestellung geben).

Es gibt z. B. im deutschen Firefox keine Icons, hier ist von Symbolen die Rede. Buttons sind Schaltflächen, Toolbars zumeist (abhängig vom Kontext) Symbolleisten. Toolbar Buttons erscheinen dementsprechend als Symbolleisten-Schaltflächen etc.

Um eine Auseinandersetzung mit der gängigen Mozilla-Terminologie kommt man also nicht herum. Wir können nur jedem Übersetzer, der seine Aufgabe ernst nimmt, empfehlen, nebenher eine englische Version des entsprechenden Programms zu betreiben, um einen direkten Vergleich zu den jeweils angesprochenen Elementen und auch Funktionen zu haben.

Sollte ein Begriff noch nie verwendet/übersetzt worden sein, so bitte auch die Hinweise im Abschnitt Benutzerfreundlichkeit/Eindeutigkeit beachten.

Formulierung/Stil

In Übersetzungen sollte der „Du-Imperativ“ vermieden werden (Lösche…, Akzeptiere…, Lehne…, etc.). Stattdessen wird der Infinitiv verwendet.

Beispiel: XYZ anzeigen statt Zeige XYZ

Benutzerfreundlichkeit/Eindeutigkeit

Hier muss man sich vor Augen halten, dass viele Entwickler selbst keine „Native English Speaker/Writer“ sind und zudem als Autoren natürlich einen anderen Blick auf ihre Werke haben (und auch nur Menschen sind, die mal Fehler machen).

Oftmals ist es daher ratsam, Formulierungen zu hinterfragen und ggf. etwas freier und somit erklärender zu wählen oder den Gegebenheiten der deutschen Sprache anzupassen, um eine bessere Verständlichkeit zu bieten. Die Bezeichnung sollte möglichst eine einfache, aber auch eindeutige Funktionsbeschreibung sein.

Anrede

Stellenweise verwandt mit dem vorherigen Punkt: Den Benutzer nie duzen! Des Weiteren sollte ein „Sie“ grundsätzlich aber auch gemieden und nur in Fällen verwendet werden, in denen es einer direkten Ansprache des Nutzers bedarf. Ausnahme: Social Media. Bei Texten, die auf Facebook und Twitter veröffentlicht werden, wird generell das „Du“ eingesetzt.

Metaphern & passende Übersetzungen

Sprichwörter und Floskeln, welche im Deutschen nicht geläufig sind, werden durch ein passendes Sprichwort ersetzt oder falls nicht möglich umschrieben. Zum Beispiel:

• "Dog eat dog" / "Der Stärkere gewinnt"
• "kick-off meeting" (Referenz auf American Football) / "Auftaktveranstaltung für ein größeres Projekt"

Marken- und Produktnamen

Markennamen mit Markenrichtlinien von Mozilla wie "Firefox" oder jene anderer Unternehmen und Organisationen dürfen nicht übersetzt werden. Weitere Informationen dazu hier: https://www.mozilla.org/en-US/styleguide/identity/firefox/branding/ (auf Englisch). Für Marken, welche eindeutig über keine Markenrichtlinien verfügen, muss die Community entscheiden, ob diese übersetzt werden sollen oder nicht. Falls die Marke ins Deutsche übersetzt wird, so muss sie folgender Liste hinzugefügt werden.

Eine ausführliche Liste, welche Produktnamen lokalisiert werden dürfen, ist hier verfügbar (Stand: Dezember 2015).

Zahlen

Tausenderstellen werden mit Punkten getrennt, das Komma ist das Dezimaltrennzeichen:

Beispiel: 1.234,56

Datum

Tag und Monat werden als Zahl jeweils mit zwei Stellen geschrieben (eine führende 0 wird falls nötig eingefügt). Das Jahr wird vierstellig geschrieben:

Beispiel: 03.05.2015

Achtung bei der Übersetzung: Amerikanische Datumsangaben enthalten an erster Stelle in der Regel den Monat, d.h. mit 05/03/2015 ist der 03. Mai 2015 gemeint.

Rechtliche Texte

Projekte von Mozilla enthalten oft rechtliche Texte wie Benutzervereinbarungen, Datenschutzerklärungen usw. Beim Korrekturlesen von rechtlichen Texten sollten Übersetzer darauf achten, dass die aufgestellten Regeln beachtet werden.

Zeichenkodierung

Alle Übersetzungsdateien (.dtd, .properties) müssen im UTF-8-Format (ohne BOM) gespeichert werden. Dazu benötigt man unbedingt einen Editor, der es erlaubt, beim Abspeichern die Zeichenkodierung des Dokuments festzulegen, beispielsweise Notepad++ oder SciTE. In .dtd-Dateien müssen bestimmte Zeichen maskiert werden:

Hinweis: Zeichenketten wie %S oder %1 dürfen nicht verändert werden, da es sich hierbei um Platzhalter handelt.

Quellen

erweiterungen.de: Informationen für Übersetzer

How to Firefox in German

Dieses Dokument soll die Erstellung und Lokalisierung von Texten erleichtern – für optimal aufbereitete und konsistente Inhalte. Wichtig hierfür sind:

• Persönlichkeit & Tonalität
• Glossar

Das Dokument spiegelt den aktuellen Stand wieder. Unsere Marke entwickelt sich aber immer weiter, sodass Aktualisierungen weiterhin vorgenommen werden.

Warum ist dieser Guide wichtig für die Lokalisierung unserer Texte?

Unsere Texte sollen nicht nur eins zu eins übersetzt werden, sondern unsere Markenpersönlichkeit und Tonalität widerspiegeln und für den kulturellen und linguistischen Hintergrund optimiert werden. Die emotionale Intention des Ausgangstextes soll adaptiert werden.

Unsere Markeneigenschaften bestimmen dabei die Tonalität der englischen als auch deutschen Fassung. Dieser Guide soll dabei helfen, Firefox als Marke besser zu verstehen, um ein besseres Gefühl dafür zu bekommen, wie die Texte in der deutschen Sprache klingen sollen. Außerdem teilen wir hier festgelegte, unternehmensspezifische Schreibweisen, die den Lokalisierungsprozess erleichtern sollen.

About Firefox – wer wir sind

Firefox ist mehr als nur der Browser. Firefox ist bietet ein ganze Reihe an Produkten, die Menschen dabei helfen sollen, online sicherer zu sein.

Firefox ist eine Challenger-Brand, die als Herausforderer den Status quo infrage stellt und sich für die Online-Rechte der Nutzer stark macht.

Bei allem was wir tun, stellen wir die Rechte und Bedürfnisse der Menschen, die unsere Produkte nutzen, an die erste Stelle. Und als Tech-Unternehmen stellen wir Menschen immer über Profit.

Firefox als Marke vereint den Firefox Ethos und die sich erweiternde Bandbreite der Produkte. (Mozilla ist dabei die Non-Profit-Organisation, die hinter Firefox steht.)

Brand promise:

Firefox fights for you

(Wichtig: Dieser Claim wird nie ins Deutsche übersetzt. Wir benutzen ihn in der deutschen Kommunikation ebenfalls auf englisch)

Wofür kämpfen wir:

Firefox kämpft für seine Nutzer/innen – mit Produkten, die Menschen auch online die Kontrolle über Leben geben.

Firefox Produkte:

• Firefox Browser (Desktop-Browser)
• Firefox Mobile (für iOS und Android)
• Firefox Send (versendet Dateien bis zu 2.5 GB per verschlüsseltem Link, der automatisch abläuft)
• Firefox Monitor (überprüft E-Mail-Adressen auf Datenleaks)
• Firefox Lockwise (Passwort-Manager)
• Pocket (Qualitätsinhalte aus dem Web)
• Firefox Reality (VR Browser)

Persönlichkeit & Tonalität

Mit wem sprechen wir?

Wir beschreiben unsere Zielgruppe als Conscious Choosers. Damit sind Menschen gemeint, die bewusste Entscheidungen treffen oder treffen wollen – online und offline.

Conscious Choosers:

• entwickeln Vorlieben und Konsumentscheidungen sorgsam und bewusst
• streben danach, Handlungen mit ihren Werten und Idealen in Einklang zu bringen
• sind anspruchsvolle Kunden
• recherchieren oft selbst, um alle Optionen zu kennen und zu verstehen

Unsere Markeneigenschaften/Firefox Brand Personality

Unsere Marken- Persönlichkeit wird von dem Zusammenspiel dieser Eigenschaften definiert. Je nach Kontext kann eine Eigenschaft deutlicher oder weniger deutlich hervorstechen.

Ansprache/Tonalität

Unsere Sprache ist:

DU vs. SIE

Firefox

Ganz im Sinne des Community-Gedankens verwenden wir “du”. Das ist unkomplizierter, emotionaler und aktivierender.

“Du” wird dabei – außer natürlich am Satzanfang – klein geschrieben.

Tipps für SEO-Texte

• Auch SEO-Texte sollen nicht eins zu eins übersetzt, sondern so lokalisiert werden, dass sie einen Mehrwert für den Leser schaffen und kulturell relevant sind.
• Titel sollten so spezifisch wie möglich formuliert werden und nicht das Übergeordnete Thema, sondern immer das konkrete Thema beschreiben (Bsp.: geht es um digitale Privatsphäre, sollte im Titel nicht stehen: Alles, was du über Privatsphäre wissen musst.

Tipps für Blog-Artikel

• Auch hier sollte der Titel so eindeutig wie möglich sein
• Die ersten 1-2 Sätze werden beim Einbau als Teaser übernommen. Hier sollte der Leser bestenfalls schon erkennen, was im Text etwa abgedeckt wird bzw. Lust bekommen weiterzulesen. (Teaser werden so angezeigt: https://blog.mozilla.org/firefox/de/)
• Zwischenüberschriften

Beispiel-Posts:

• https://blog.mozilla.org/firefox/de/firefox-versprechen-fuer-deine-persoenlichen-daten/
• https://blog.mozilla.org/firefox/de/so-schuetzt-du-deine-daten-auf-reisen/
• https://blog.mozilla.org/firefox/de/join-firefox/
• https://blog.mozilla.org/firefox/de/loesche-deinen-digitalen-fingerabdruck-in-firefox/
• https://blog.mozilla.org/firefox/de/so-blockierst-du-krypto-mining-auf-deinem-computer-mit-firefox/
• https://blog.mozilla.org/firefox/de/add-ons-fuer-digitalen-fruehjahrsputz/
• https://blog.mozilla.org/firefox/de/online-tracking-hol-dir-die-kontrolle-zurueck/
• https://blog.mozilla.org/firefox/de/firefox-fights-for-you/
• https://blog.mozilla.org/internetcitizen/de/2018/10/29/sichere-zuallererst-deine-passwoerter/
• https://blog.mozilla.org/firefox/de/das-original-unter-den-alternativen-firefox/
• https://blog.mozilla.org/firefox/de/firefox-monitor-dein-schutz-vor-hackern/

Glossar

Immer wiederkehrende Schreibweisen bei Firefox Englisch-Deutsch

Die hier aufgeführten Begriffe werden häufig in unserer Kommunikation verwendet. Und sollten aus Konsistenzgründen bevorzugt eingesetzt werden.

Bei Unsicherheiten kann auch die Transvision Suche konsultiert werden. Da in der Suche aber häufig auch ältere Übersetzungs-Versionen in der Ergebnisliste (oft noch mit der formalen Ansprache) angezeigt werden, dient dieses Tools eher als Orientierungshilfe.

Folgende Begriffe und Schreibweisen gelten jedoch immer:

Unternehmensspezifische Schreibweisen/Firefox Claims:

Allgemeine Schreibweisen

Überschriften, Aufzählungen und Formatierungen

Mozilla Tone of Voice & Localisation Guide (German)

Warum ist dieser Guide wichtig für die Lokalisierung unserer Texte?

Unsere Texte sollen nicht nur eins zu eins übersetzt werden, sondern unsere Markenpersönlichkeit und Tonalität widerspiegeln und gleichzeitig für den kulturellen und linguistischen Hintergrund optimiert werden. Die emotionale Intention des Ausgangstextes soll adaptiert werden.

Why is this guide important for the localization of our copy?

Our copy should not only be translated one-to-one, but should reflect our brand personality and tonality and be optimized for the cultural and linguistic background. The emotional intention of the source text should be adapted.

Ansprache + Tonalität/Tonality