L10n:WorldReady/Screenshot Guideline

From MozillaWiki
Jump to: navigation, search


There are two way of creating the screens. One is by taking a screenshot using a functioning and localized product. Another is by translating all the strings based on an en-US mockup in a spread sheet, then replacing the English strings with localized one in an image creating software. The former requires guidelines on the specification for the screenshot, the latter relies an creative agency to implement localized content. With each solutions, there are pros and cons.

Capturing Screenshots

  • Pros:
  1. Ensure the UIs are correct or product is ready before capturing a screenshot
  2. Can set up the environment to have relevant messages, contact list, events in calendar
  3. Time saving by create data inventory (contacts, email messages, events in calendar) for future reuse vs one-time effort by creative agency.
  4. No issues of possible inconsistency with terminologies
  5. No issues of multiple localizers using different terms for the same English word/phrase
  6. No concerns of missing accent, truncated text
  7. Won't have mixed languages in screenshot/composite image
  8. QA the screenshot/composite image early on.
  • Cons:
  1. A QAed working product may not be ready until late in the development cycle, which may be too late for PR.
  2. Screenshot resolution may not be high enough for printing large poster for PR and Marketing purpose, but should be fine for Help documentation or Web content.
  3. Need instruction/steps up front to take desired screenshots. Instruction could be device specific
  4. May not be able to produce desired resolution/size by all linguists, depending on the software availability in target market (Remedy: A linguistic vendor will be able to solve this problem).
  5. May not complete all desired screenshot/composite images at the same time across all locales (but won't be the case if done by linguistic vendor).

Creating Screenshots

  • Pros:
  1. As soon as mockup is approved, localizable strings can be identified and translated
  2. Creative agency assembles the final images that may require high resolution for printing purpose.
  3. Long lead time before launch, can be worked on simultaneously while the product is still being developed.
  • Cons:
  1. Possible English terminology inconsistency between mocks and actual product
  2. Possible terminology inconsistency between translations for the product and the mocks if the translations were provided by two different localizers.
  3. Creative agency implements text using software that may or may not have fonts that support the non-Latin-1 characters.
  4. Creative agency may look terms up through online translation tool to quickly fix last minute translation request, which could introduce localization errors
  5. Creative agency usually doesn't have an eye to spot localization issues. Missing accented letters, truncated text or text breaking at the wrong place can introduce additional errors during implementation.
  6. More time needed to accommodate reviews between localizers and creative agency.

Preparation for Capturing Screenshots

As shown above, overall it is better to take screenshots from a working product rather than creating a screenshot. However, it takes time to set up the environment to take the screenshots. With the right process and proper guidelines and instructions, it is easy to do, especially the data and environment can be easily leverageable from one version of the product to another.

More information will be added as we have more apps developed.

  • MAPS:
  1. Select the target language
  2. Select a well known city, such as the capital of the country and the landmark of the city
  3. Make sure the map road signs appear in the target language, not English

It's important to create an inventory of contact list before taking screenshot. Be sure these are clean and valid ones associate to a test account so it can be reused in the future. By "clean", it means there is no words like fake email domain names, phone number doesn't comply to the correct format, and names sound like native names.

  1. Create a list of names common in the target language/country
  2. Create a phone number associate with each contact in the format compliant to the target market [US/CA: (xxx)xxx xxxx; CN: xx-xxxx-xxxx (landline) or 1-xxxxxxxxxx (mobile), TW: x-xxxx-xxxx, PL: (xx) xxx xx xx ]
  3. Create an address associate with each contact in the format compliant to the target market
  4. Create a *valid* email address, even though this is a test account. Avoid fancy or "test" sounding user names. Be sure to use one of the more recognizable domain names for email address
  5. Verify that the sorting order is correct for the target language
  • EMAIL:
  1. Create several emails between friends on various subjects: play games, plan for the weekend/vacation, meet at coffee, go to concert...
  2. Make sure a single contact has several incoming emails with various subjects.
  3. Avoid test sounding emails
  4. Make sure incoming emails have valid sounding names (vs. test sounding).
  5. Make sure emails are in target language, with correct spelling and grammar.
  1. Create events in target language
  2. Create several events in target language, some of reoccurring events and others one time only
  3. Create enough events to have a solid 1 week view or 1 month view
  4. Make sure events are not several years old so it appears events are still fresh
  5. Screenshots are taken in the target language.
  6. Is there option in the calendar to chose lunar calendar of a particular culture over Gregorian calendar? If so, lunar calendar may highlight the offering of the product.
  7. Date and time format should display correctly.
  • PHOTO: Stock up photos on
  1. Ethnically relevant people shot
  2. Relevant landscapes
  3. Relevant activities to the region/country
  4. Culturally not offensive to certain countries
  • MUSIC: Stock up audio tracks on
  1. World-wide recognizable bands
  2. Bands locally known
  • VIDEO:
  1. Similar to Photo section

Guidelines to Capturing the Screenshot/Creating Composite Image

If the community or a localization vendor were to take the screenshots, the following info is needed:

  1. Screenshot dimension: dpi, height and width to ensure the basic level of resolution is met.
  2. If it is a composite image, edible source files as templates are needed, in commercially available format (illustrator, Photoshop...).
  3. Both output and source files are needed, not just the source files alone
  4. Indicate which layer needs to be replaced with localized content
  5. The size of final output of a composite image: dpi, height and width
  6. File Type: jpg, png, psd, TIFF, gif
  7. File name: standardize the file name for easy identification. Recommended naming convention for example FileName-xx.jpg (xx indicate the locale name).
  8. If a series of screenshots to be taken or composite images to be made, consider creating a folder, with the folder named in the target locale for easy file management.
  9. Provide file repository location: dropbox, google doc or FTP can work both for file handoff and file deliveries.
  10. Always request the delivery of the final source files should final tweak is needed internally.

Review of the Final Output

All screenshots/composite images must be reviewed by native speakers before release/use.

  • Verify screenshot that it (when applicable)
  1. still reflects the most current product UIs; if not, retake the screenshot.
  2. has the correct date/time format
  3. has no grammatical error and spelling mistakes in email messages and calendar events
  4. has no truncated text that may have very bad meaning.
  5. is in the same language between the app and the content, such as email app and its messages, the calendar app and its events
  6. has the right kind of common names for the language/market, accents are not missing, sorting order is correct
  7. has the right location in the map app in the right target language with accents in tack
  8. corresponds to the same language the file is named
  • Verify composite image that it (when applicable)
  1. doesn't contain a mix of two or more languages
  2. contains the same elements/screenshots that make up the composite, compared to the reference version (presumably US version)
  3. has the correct file name/locale that matches the same language the composite is for
  4. has the proper size/resolution it is intended for