පරිවර්තන මඟපෙන්වීමේ අපි පරිවර්තනයක තත්වය තිරණය කරන මිනුම සඳහන් වේ. Mozilla නිමැයුම්, වෙබ් පිටු සහ අනෙකුත් ව්යාපෘතීන්හි පරිවර්තන කරන්නේ කෙසේද යන්න පිළිබඳ Mozilla සහ Mozilla පරිවර්තන කණ්ඩායම් විසින් පිහිටුවන ලද නීති රීති මෙහි අඩංගු වෙයි. පරිවර්තන මඟපෙන්වීම පරිවර්තන කිරීම සඳහා මෙන්ම පරිවර්තනයක තත්වය නිර්ණය කිරීම සඳහාද භාවිතා වෙයි. මෙම නීති රීති පිළිපැදීම මඟින් Mozilla අගයන් සහ සංස්කෘතිය නිරූපනයවන තත්වයෙන් වඩාත් උසස් පරිවර්තනයක් කිරීම අවස්ථාව පරිවර්තකයෙකුට ලැබේ.
මෙම මඟපෙන්වීම කොටස් දෙකකින් සමන්විත වෙයි: පළමු කොටසේ Mozilla සිංහල පරිවර්තන ප්‍රජාව විසින් පිළියෙළ කරන ලද භාෂා මූලික නීති රීති (භාෂා මූලික විලාස, පාරිභාෂික වචන සහ මිනුම් ඒකක ආදිය ආවරණයවන පරිදි) සඳහන්වන අතර දෙවන කොටසේ ඔබට වඩාත් හොඳින් පරිවර්තන කිරීම සඳහා Mozilla විසින් සියළු භාෂා සඳහා නිර්ණය කරන ලද සාමාන්‍යය නීති රීති (නිරවද්‍යතාව සහ ව්‍යක්තභාවය පිළිබඳ මූලධර්ම ආවරණයවන පරිදි) සඳහන් වෙයි.
පරිවර්ථන සැකසුම නිර්ණය කිරීමේදී භාෂාවේ විධිමත් බව හා Mozilla l10n ව්‍යාපෘතියට විධිමත් හඬ භාවිතය නිර්ණය කිරීමේ දී සැලකිය යුතු ප්‍රධාන කරුණු සලකා බලමු.
මෙම ව්‍යාපෘතිය ඉලක්ක කරන පරිශීලකයා කවුද? ඔහුගේ පසුබිම කුමක්ද? ඉලක්කගත පරිශීලකයා මෙම ව්‍යාපෘතිය සමඟ අන්තර්ක්‍රියා කිරීමට අදහස් කරන්නේ කෙසේද? උදාහණයක් ලෙස, ඔවුන් සරල, මිත්‍රශීලී අන්තර්ක්‍රියාවක් බලාපොරොත්තු වන්නේද? අපගේ භාෂාව සඳහා වන සියළු Mozilla L10n ව්‍යාපෘති සඳහා විධිමත් භාෂාව ගැලපෙන්නේද, එසේ නොවන්නේ කුමන අවස්ථා වලදීද? අපගේ භාෂාව සඳහා වන සියළු Mozilla L10n ව්‍යාපෘති සඳහා අවිධිමත් භාෂාව ගැලපෙන්නේද, එසේ නොවන්නේ කුමන අවස්ථා වලදීද?
මූලිකව, දේශීයකරණයේදී අනවශ්‍ය ලෙස විධිමත් බව ඉහල හෝ පහළ දැමීම සිදු නොකළ යුතුයි. මෙයට උදාහරණය වන්නේ, "ක්ලික් කරන්න" (අවිධිමත්) "කරුණාකර මෙහි ක්ලික් කරන්න" (වඩා විධිමත්). තවද භාෂාවේ භාවිතය සම්පූර්ණ ව්‍යාපෘතිය තුළම එකාකාරී විය යුතුයි.
ස්වභාවික ප්‍රකාශනයන් භාවිතයෙන් ඔබේ දේශීයකරණය එය කියවන්නාට වඩා ස්වබාවික බවක් එක් කරයි. ඔබගේ පරිවර්ථනය පිළිගත් භාශා නියාමකයන්ගෙන් බාහිරව දේශීය හා ස්වභාවික ප්‍රකාශනයන් අඩංගු කර ඇති විට ලැබෙන ප්‍රථිපලය දුර්වල වේ. පරිවර්ථනයේදී මේ පිළිබඳව වඩාත් සැලකිලිමත් වීමට නිර්දේශ කරන්නෙමු. උදාහරණයක් වශයෙන් "From Scratch" යන්න සරල පරිවර්ථනයේදී "සීරීමෙන්" යනුවෙන් යෙදෙන නමුත් එහි සත්‍ය තේරුම "මුල සිට ඇරඹීම" වේ.
සිංහල භාෂාවේ සහ ඉංග්‍රීසි භාෂාවේ ව්‍යාකරණ වෙනස නිවැරදි ලෙස පරිවර්තනය විය යුතුය. එබැවින් පරිවර්තනයේදී ලබාදීමට උත්සාහ කරන අදහස නිවැරදිව සටහන් වීමට නම් මෙම වෙනස්කම් පිළිබඳව සැළකිලිමත් වීම වැදගත්ය. පහත උදාහරණයේදී “#1” මඟින් සංඛ්‍යාවක් දක්වන අතර ඒ අනුව එහි ස්ථානය වෙනස් කර නිවැරදි අදහස ලබාදිය යුතුය.
- “Downloading and verifying add-on…;Downloading and verifying #1 add-ons…”
- “ඇඩෝන බාගත කරමින් හා පිරික්සමින් සිටියි…;ඇඩෝන #1 බාගත කරමින් හා පිරික්සමින් සිටියි…”
ක්‍රියාපද පරිවර්තනයේදී ඉදිරිපත් කිරීමට බලාපොරොත්තු වන අදහසට හානියක් නොවන පරිදි හැකි තරම් කෙටිකර දැක්වීමෙන් මෙනුවේ හෝ දෝෂ සටහනේ එය දර්ශණය වීම පහසු කරවනු ඇත.
උදාහරණ ලෙස “Analyse” පරිවර්තනයේදී “විශ්ලේෂණය” ලෙස දැක්වීම ප්‍රමාණවත් වන අතර “විශ්ලේෂණය කරන්න” ලෙස දැක්වීම අවශ්‍ය නොවේ. “Back to Top” පරිවර්තනයේදී “යළි ඉහළටම” ලෙස දැක්වීම ප්‍රමාණවත් වන අතර “යළි ඉහළටම යන්න” ලෙස දැක්වීම අවශ්‍ය නොවේ.
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.
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).
පරිවර්තන ව්‍යාපෘතියක් පුරාවටම Mozilla සහ තෙවැනි පාර්ශවීය සන්නාම සහ විලාස මඟපෙන්වීම්වලට ගරුකල යුතුයි. Mozilla මූලික සන්නාම නීති සඳහා වැඩිදුර විස්තර සඳහා https://www.mozilla.org/en-US/styleguide/identity/firefox/branding/ වෙත පිවිසෙන්න. උදාහරණයක් ලෙස "Firefox" වැනි සන්නාම නාම කොහෙත්ම පරිවර්තනය නොකළ යුතුයි. සන්නාම මඟපෙන්වීම් නැති අනෙකුත් සන්නාම පරිවර්තනය කළ යුතුද නැත්ද යන්න සිංහල පරිවර්තන ප්‍රජාව ලෙස අප තීරණය කල යුතුයි. සන්නාම නාම පරිවර්තනය කිරීමට තීරණය කිරීමට පෙර සන්නාම නාම පිළිබඳ සුපරික්ෂාකාරී වන්න (Mozilla හෝ අනෙකුත් තෙවැනි පාර්ශවීය සන්නාම සඳහා). එවැනි සන්නාම පරිවර්තන පිළිබඳ මෙම පිටුව යාවත්කාල කිරීමට කාරුණික වෙන්න.
පරිවර්තනයේදී දැනට භාවිතාවන, විශ්වාසිත සහ අදාල සිංහල වචන මූල භාචිතා කිරීමට වගබලාගන්න. පහත සඳහන් කරුණු නොකිරීමට කාරුණික වෙන්න:
ව්‍යාපෘතියේ නොගැළපෙන පාරිභාෂික වචන භාවිතය
වචන මූලයේ නොගැළපෙන පාරිභාෂික වචන භාවිතය ඔබගේ සියළු ව්‍යාපෘතිවල නොගැළපෙන පාරිභාෂික වචන භාවිතය වෙනත් මාතෘකාවකට අදාල පාරිභාෂික වචන භාවිතය (උදාහරණයක් ලෙස 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:
Reference material can be find here: https://en.wikipedia.org/wiki/Date_format_by_country
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?
- මිනිත්තු 5 කට පෙර
- ජනවාරි 9 දින පව 9:16 ට
රුපියල් 10ක්, රු 100 ක්
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.
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]
Space separators between digits can be different for area codes such as State (Province) and City
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.
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
An abbreviation is a shortened form of a word. 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)
Abbreviate text if space is an issue or to make the text easier to read at a glance.
- Century – 20 වන ශතවර්ශය
- Decades – 80 දශකය, 90 දශකය
- Months – ජන, පෙබ, මාර්, අප්‍රේ, මැයි, ජුනි, ජූලි, අගෝ, සැප්, ඔක්, නොවැ, දෙසැ
- Dates – ජන 10, මාර් 11
- Days – ඉරිදා, සදුද, අඟ, බදා, බ්‍රහ, සිකු, සෙන හෝ ඉ, ස, අ, බ, බ්‍ර, සි, සෙ
- Hours – මිනි, තත්, පෙ.ව., ප.ව. (උදා: පෙ.ව. 1, ප.ව. 2.30)
- Other common usages:
- Examples – උදා: උදාහරණ
- info (no period) – ඉඩ අවශ්‍ය පරිදි ඇත්නම් ‘තොරතුරු’ ලෙස භාවිත කරන්න.
- US - එ.ජ. හෝ එ.ජ.ඇ.
There is no standard translations of widely accepted acronyms such as CD, DVD, MB, TCP, SMS in Sinhala. So keep them remain in English (see: https://en.wikipedia.org/wiki/Acronym )
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?
Capitalization is not available in Sinhala.
- Save, save - සුරකින්න
- Edit, edit - සකසන්න
please keep original terms as it is in English, in case of entire word in capital letters.
The use of bold, italic, or underline types to express emphasis.
First translate (without considering text formatting) and then make relevant text formatting in respective words or strings.
What is the appropriate way of using hyphens and compounds in your language? ( https://en.wikipedia.org/wiki/Compound_%28linguistics%29)
What is the appropriate form of expressing prepositions and articles in your language?
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)
Does your language have a standard use for quotation marks, parenthesis, or brackets?
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)
- 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.
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.
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.