Style Guide Yoruba (yo)

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 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. Yoruba language encapsulates both formal and casual texts.
• 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 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 products.

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 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. Yoruba language has VERY few words that can be written as abbreviations. For example, e.g. = b.a; etc = abbl

Measurements and Numerals

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

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.

If the source text does not do so, and if possible, spell out an abbreviation or acronym the first time it is used in a document, followed by that abbreviation or acronym in parentheses.

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

Articles

Product Names

• Mozilla product names are used without definite or indefinite articles. They are treated as proper names. This structure is admissible in Yoruba language; yet the consistency of the concerned term will not be compromised.

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. If in doubt, please contact the Rubric Project Manager.

The same product may be marketed under different names in different countries. One solution is to add a note saying "Marketed as -------- in the UK etc" the first time the product is mentioned, and then continue to use the name as given in the text.

During Google Nigeria and Sony-Ericsson translation projects, trademarked are not translated. E.g. Bluetooth, Google, etc.

Translation of Version Strings

• Please use the following guidelines when localizing version strings:

Gender-neutral Translation

All Yoruba nouns and pronouns are neuter. For instance:

• He/She/It = Ó
• his/her/its = rẹ̀ etc

Genitive

Since Yoruba language is neuter there are hardly specific consideration in affixations. Except in very rare occasions.

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.

Gender

As stated above.

Inflections

Inflections in Yoruba language do not reflect in the written form

Plural Formation

Plurals are indicated by adding ‘awọn’ to the nouns. e.g.

SINGULAR AND PLURAL – ẸYỌ ÀTI Ọ̀PỌ̀

The article ‘àwọn’ is used to express plurality of Yoruba nouns. For instance:

Verbs and Verb Forms

PRESENT, PAST, AND PARTICIPLE TENSES

SIMPLE AND CONTINUOUS TENSES

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.

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.

Key Names

• On the first mention, use the definite article and "key" in conjunction with the key name, for example, "the ESC key". On all subsequent references, refer to the key only by its name, for example, "Click ESC".
• As a rule of thumb, be frugal in your use of the word "key". Use it if the key name appears alone in the sentence and the actual key name does not appear on the keyboard.

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

Procedural Headings

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

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.