Hello Gustavo We are currently creating a Brazilian Portuguese Style Guide. You are more than welcome to have a copy on completion (est mid Dec). The completed languages available at present is English, Japanese, French, German, Spanish, Italian, Swedish. We are also currently working on completing Simplified Chinese, Traditional Chinese and Korean. Not to effect everyone's mail server, I will send you a separate mail with a copy of our English Style Guide which you can use as a basis to generate the Brazilian Portuguese Style Guide. I will also attached our International Spanish Style Guide as reference. We work with approved freelancers who perform linguistic quality assurance feedback on our projects. They are mainly responsible for performing QA's on various samples of the files and reporting their findings. The QA feedback report is returned to the translators who implements the recommended changes. However, depending on the language and the project requirements, the can implement linguistic changes to the files if necessary. The QA is aimed to ensure consistency across applications and/or components such as UI, Help and documentation. Attached is a copy of the template which is completed during the QA, "SUN_QA_Matrix2.html" Gustavo, I can have our Brazilian Portuguese freelancer perform a QA on GNOME translations and report his/her feedback to the Brazilian Translation Team. Let me know if you are interested. Bye for now Aoife > Date: Wed, 01 Nov 2000 21:25:22 -0200 > From: Gustavo Maciel Dias Vieira <gdvieira@zaz.com.br> > X-Accept-Language: en > MIME-Version: 1.0 > To: Aoife Dunne - Sunsoft ELC <Aoife.Dunne@ireland.sun.com> > CC: gnome-i18n@gnome.org > Subject: Re: open translations database > Content-Transfer-Encoding: 8bit > X-MIME-Autoconverted: from quoted-printable to 8bit by ireserver.Ireland.Sun.COM id AAA15619 > > Aoife Dunne - Sunsoft ELC wrote: > > > > > > Style Guides > > ------------ > > We have some localised versions of a style guidelines. These > > guidelines are used to aid the translators. For example, in > > France how the date, time formats should be localised. In many > > countries such data is correct in many formats, however, the use > > of style guides decide on the preferred format for the use of > > consistency. Our style guides could be used as reference and > > updated to create a GNOME specific style guide for all languages. > > Let me know if you are interested and I will send you a copy of > > our country specific style guides. > > Hello, Aoife > > Do you fine folks at Sun have a brazilian portuguese team? > I'm starting to write a style guide for brazilian translators and would > love to receive a copy of yours style guide, if available for brazilian > portuguese. > > > > > > How else can Sun help, > > > > * possible act a the host for the translation memory database, > > populating newly translated products. > > > > * provide linguistic quality assurance feedback and implement > > linguistic changes if necessary checking for grammar, spelling, > > inconsistencies etc. > > How do you plan to provide QA for translations? Is it avaiable for > brazilian portuguese? > > Abraços, > Gustavo > > -- > gdvieira@zaz.com.br > http://www.dcc.unicamp.br/~ra941486 Aoife Dunne Program Manager European Localisation Centre Sun Microsystems Ireland Ltd Hamilton House East Point Business Park Dublin 3 Ireland Tel.: +353-1-8199-266 Fax:. +353-1-8199-261 Email: aoife.dunne@Ireland.Sun.COMTitle: SUN Quality Assurance Matrix
SUN Quality Assurance Document
QA CHECKLIST – To be filled in by LS
|
Product name |
|
|
Platform/Product line/Version |
|
|
Code |
|
|
Language |
|
|
QA phase |
|
|
Date |
|
|
List of files QAed |
|
|
Completed Call-for-Work document received? |
|
|
Any outstanding queries in the sample QAed? |
Important note: Please note that the Linguistic Specialist is required to fill in all applicable fields and most importantly that a Pass/No Pass valuation is given for each applicable category as well as for the overall assessment. Please also supply a high-level summary assessment at the beginning of you report which should be directed to the Project Manager. All comments apart from specific language examples and corrections must be given in English.
Important note: If the linguist at any stage during the QA cycle deems the translation to be not fit for QA, the QA cycle should be interrupted and the translation together with an initial report returned to the vendor immediately for editing/correcting. Another day should be earmarked for a second QA cycle. It is of greatest important that the vendor gives priority to correcting the translation so that the second QA cycle can take place as soon as possible.
SUMMARY REPORT ON THE TRANSLATION
|
SUMMARY: …
SIGNATURE & DATE: ___________________________________________________________
|
REPORT
|
Location of error |
US text |
Translated text |
Description of error/issue |
Required/suggested correction |
Comments |
Explanatory comments:
‘Location of error’ may include a book name, page number, file name, URL, path followed to SW item a numbering structure, etc. The location must be unique or in the case of a general comment, this must be clearly marked as ‘global’.
The ‘US text’ may be optional but must be included if the translation error is of the type mistranslation, omission, or misunderstanding of original.
The ‘Translated text’ must be quoted exactly as it appears in the document.
The ‘Decription of error/issue’ must be as per the error categories listed above. All descriptions of errors must be given fairly and non-subjectively.
A ‘Required/suggested correction’ must be offered by the Linguistic QA Specialist, except where there are large passages left untranslated which must be provided by the original vendor/translator.
‘Comments’ is an optional column which may be used by the vendor if he strongly disagrees with corrections suggested by the Linguistic QA Specialist.
Important note: Sometimes corrections are of the type that instead of one grammatical construction (e.g. noun construct) another grammatical form (e.g. infinitive) should be used, particularly in (sub)headings or captions. E.g. not ‘Bearbeiten von Bildern’, but rather ‘Bilder bearbeiten’. In such cases, these global changes need be quoted only once (but marked ‘global’) if the corrections are to be implemented by the vendor. The must be quoted for each and every instance if the corrections are to be implemented by an engineer in SUN.
COMPLIANCE CHECKLIST – DOCUMENTATION/HELP
ERROR CATEGORY: Accuracy
|
Error type |
Max. errors allowed |
Errors found |
|
Omissions/additions (e.g., text, callouts, titles, index markers, graphics) |
||
|
S/W references incorrect |
||
|
Mistranslations |
||
|
Headers/footers incorrectly translated |
||
|
TOC/Index errors |
||
|
Cross-references/index markers deleted |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Terminology
|
Error type |
Max. errors allowed |
Errors found |
|
Glossary not adhered to |
||
|
S/W references incorrect |
||
|
Inconsistent terminology |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Language
|
Error type |
Max. errors allowed |
Errors found |
|
Semantics |
||
|
Spelling |
||
|
Grammar |
||
|
Punctuation |
||
|
Hyphenation |
||
|
Cross-referencing |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Style
|
Error type |
Max. errors allowed |
Errors found |
|
General style |
||
|
Register/tone |
||
|
Style guide not followed |
||
|
Language variants/slang |
Acceptable level: 0 - 4 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Country
|
Error type |
Max. errors allowed |
Errors found |
|
Country standards |
||
|
Local suitability |
||
|
Company standards |
||
|
Translation guide-lines not followed (if applicable) |
Acceptable level: 0 - 4 error per 1000 words
No. of errors: Rating : Pass No Pass
Overall rating: Pass/No Pass
Requires second QA cycle: Yes/No
COMPLIANCE CHECKLIST – SOFTWARE
ERROR CATEGORY: Accuracy
|
Error type |
Max. errors allowed |
Errors found |
|
Omissions/additions |
||
|
Mistranslations |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Terminology
|
Error type |
Max. errors allowed |
Errors found |
|
Glossary not adhered to |
||
|
Inconsistent terminology |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Passed Failed
ERROR CATEGORY: Language
|
Error type |
Max. errors allowed |
Errors found |
|
Semantics |
||
|
Spelling |
||
|
Grammar |
||
|
Punctuation |
||
|
Abbreviations |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Functionality
|
Error type |
Max. errors allowed |
Errors found |
|
Core functionality |
||
|
Hotkey/shortcut functionality |
||
|
Platform/hardware compatibility |
||
|
Keyboard layout/code page |
||
|
UI problems (alignment, sizing, positioning, truncation) |
Acceptable level: 0 - 3 error per 1000 words
No. of errors: Rating : Pass No Pass
ERROR CATEGORY: Country
|
Error type |
Max. errors allowed |
Errors found |
|
Country standards |
||
|
Local suitability |
||
|
Company standards |
||
|
Translation guide-lines not followed (if applicable) |
Acceptable level: 0 - 4 error per 1000 words
No. of errors: Rating : Pass No Pass
Overall rating: Pass/No Pass
Requires second QA cycle: Yes/No
A Pass/No Pass must be given for both the overall rating and for all the different quality categories!
Important note: A No Pass means that the vendor must carry out an internal QA/edit of the entire translation, not just the marked up pages/chapters.
A Pass means that the suggested corrections must be implemented but that the rest of the translation can be left as is.
Reference
Ratings and ratings parameters
The aim – excellent quality
Documentation, help
Language: Describes functionality very accurately. Information correctly translated, concise and easily accessible. Consistent use of terminology and style. Adhering to glossary, style guide and any guidelines. No grammar, punctuation or spelling errors. All page references and cross-references correct. Complete index. Correct country standards used.
Formatting: All standard fonts and templates used. No paragraph style or character formatting errors. All art referenced correctly. No index, formatting or reference errors. All page references correct. Help is complete with correct alignment and no display errors.
Functionality: Documentation and help fully consistent with software. Correct art pieces inserted throughout with all callout references in documentation accurate. Technically accurate localisation with no misleading statements, showing a thorough understanding of the product. No topic or footnote errors in help.
Software
Language: No language bugs, Completely, accurately localised. Examples well localised. UI terms consistent and appropriate to platform. Adhering to glossary and SUN guidelines. Describes functionality accurately.
Formatting/functionality: Dialog boxes all correctly sized. No duplicate hotkeys. All text items localised, aligned correctly and fully visible on the screen.
What to look out for – unsatisfactory quality:
Documentation, help
Language: Product difficult to use due to omissions in translated text, mistranslations due to misunderstanding the source or lack of information. Discrepancies between software and documentation. Information difficult to access. Examples not or not well localised. Writing style poor, terminology inconsistent. Numerous grammar, punctuation or spelling errors. Serious inconsistencies, errors in page references, cross-references or index. Unacceptable errors in country standards.
Formatting: Serious formatting and layout errors. Standard fonts and templates not adhered to. Paragraph style or character formatting errors. Art not referenced correctly. Help does not compile or contains alignment and display errors. Requires a significant amount of rework to comply with market requirements
Functionality: Inconsistencies between documentation, help and software. Jumps/popups not functioning in help. Incorrect art pieces inserted or inaccurate callout references in documentation. Poor understanding of product leading to inadequate technical localisations throughout. Topic or footnote errors in help.
Software
Language: Language bugs, inadequate or incomplete localisation. Examples not or not well localised. Inconsistent UI terms or not suitable for platform used. Not adhering to glossary or SUN guidelines. Functionality not accurately expressed.
Formatting/functionality: Significant number of localisation bugs. It takes longer to report the bugs than to test the product, demonstrating a lack of any QA check before hand over. Duplicate hotkeys. Text items not aligned correctly or truncated on the screen. A significant amount of rework is required to bring the software to an acceptable standard.
The aim of this document is to outline SUN’s language quality assurance matrix.
Goals
This document provides information on how the language quality of translated products should be assessed. It outlines the criteria used for evaluating quality and describes the recommended reporting procedures.
This document is addressed to the Linguistic QA Specialists. Their core responsibilities are:
Note: Since all Linguistic QA Specialists used by SUN are a) freelance linguists and b) not involved in the translation/localisation process prior to delivery by the vendor they have no role in language support during a translation project, stylistic or terminological guidelines for translation or any scheduling issues. Their role is purely to assess the ‘finished’ and delivered translation and to suggest corrective action.
Prerequisites for a succesful QA cycle
Theses are dealt with in more detail in a separate document. The following are purely some main checkpoints.
Language criteria to be taken into consideration
The criteria used by SUN to determine quality and errors in printed and online documentation and software are:
Accuracy omissions, additions, cross-references, headers/footers
Terminology glossary adherence, consistency, context, abbreviations
Language grammar, semantics, punctuation, spelling
Style general style, register/tone, language variants/slang
Country country standards, local suitability, company standards
Functional criteria in software – GUI terminology, cross-application/cross-platform terminology, abbreviations, key combinations and sequences, core functionality, hotkey/shortcut functionality, codepage, platform/application compatibility
Formatting criteria in software – alignment, sizing, truncation, non-displaying characters
Materials to be used for the QA:
Supplied glossaries
Supplied style guide
List of outstanding queries if any
Complete Call-for-Work document
QA Feedback form supplied
Project elements and fundamental QA prerequisites
All material is provided in electronic format. QA takes place on-screen, any comments are in report format. There is no mark-up on paper except in exceptional cases such as marketing and packaging material or artwork. The file formats used for almost all printed and online documentation are HTML, SGML, and Frame (MIF). In the case of marketing material it is important to QA the PostScript files. When checking for consistency across all components, the software takes precedence over all other project elements, i.e. documentation and online help are evaluated against the software and made to conform to it. It is furthermore important to ensure that the translation is in line with other products in the product line. The major product lines in SUN are Java, Solaris and hardware-related products. There may in future be an additional educational product line.
As a rule of thumb, between 10% and 20% of a translation are QAed, or in the case of short documents a minimum of one day is set aside for QA, in which case the entire document may be checked. For longer translations the word count must be known and provided by the PMs on the Product Information Sheet.
The Linguistic QA Specialists will select 10-20% of the translation based on the word count provided. It is important to select random samples of a translation for QA, i.e. not chapters 1 to 3 but rather e.g. 10 pages from chpt. 4, all of chpt. 7, 2 appendices plus the letter M from the index checked against the relevant pages.
When checking online help, it is important to follow this sequentially by proceeding through the TOC (again the above rules for random sampling apply). Links and context-sensitivity should be checked for functionality but not as a method for proceeding through the help system. In the case of software, all of the UI must be checked plus 10-20% of other messages.
For scheduling/pricing purposes, it is assumed that a Linguistic QA Specialist can check 8000 words of printed/online documentation per day and 4000 words of software per day.
QA of printed and online documentation:
The translated document is evaluated against the base product documentation. In the case of context-sensitive online help, the compiled files are used in the evaluation. The QA takes place sequentially and not by proceeding via links or the context-sensitivity function. All printed and online documentation and context sensitive help are evaluated against the software and made to conform to it.
Software QA:
The localised compiled software is evaluated against the US software. The software QA is of critical importance. All of the User Interface as well as 10-20% other messages should be evaluated. Software QA may also involve some software testing to a lesser or higher degree. In such cases test scripts would be of great help to the Linguistic QA Specialists. On the UI a No Error Pass is required.
Other elements – packaging, marketing, legal material. For these the PostScript files or printouts are to be QAed. On all packaging, marketing and legal material a No Error Pass is required.