Child pages
  • i18n requirements and goals
Skip to end of metadata
Go to start of metadata

i18n requirements and goals (draft)

i18n requirements:

  1. Any character available in UTF-8 or through UTF-8 encoding should be available for any operation. UTF-8 should be properly escaped in URLs. UTF-8 should be preserved when importing or exporting.
    • Example: User names, titles, content, folder names, file names, import and export formats ... containing UTF-8 should be handled properly to work OOTB. "Jean-François Lévêque", "Éducation", "Rôles" and "maïs.html" (could use other languages than French).
  2. Any user-displayed self-sufficient text should be built in a way that permits it translation without being constrained by the default language structure.
    • Example: Any automated email sent to a user should be available for translation as a whole (i.e. not as parts assembled) with variable information included through identified variables with no constrained order.
      #{0}=Dropbox display name, {1}=User display name, {2}=Site title, {3}=Sakai implementation display name, {4}=Display path to resource, {5}=MyWorkspace display name, {6}=Preferences display name
      
      A new resource has been added to the {0} for {1} in the {2} site at {3}.
      
      Location: site {2} {4}
      
      This automatic notification message has been sent by {3} from the {0} in the {2} site. You can modify how you receive notifications at {5} {6}.
      
  3. The way to translate the user-displayed texts should be well documented.
    • Example: If there's a general rule, it should be explained for the release and each tool with a different way to translate should explain it.
  4. A way to debug live how the user-displayed text is built should be available.
    • Example: User-configured debug mode language available in the preferences.
  5. The display of dates, numbers and other not purely textual user-diplayed information should adapt to the locale rules of both language and country. This adaptation might be available within the framework/language used.
    • Example:
      15/03/2010 (fr_FR) <=> 03/15/2010 (default) <=> 2010-03-15 (ISO)
      1,5 (fr_FR) <=> 1.5 (default)
  6. The user-displayed information should adapt dynamically to the user preferences.
    • Example:
      "Hi {User first name}!" (default) becomes "Salut {User first name} !" when user switches his language preferences to fr_FR.
      
  7. The way the locale user preferences are retrieved should be consistent across an official release of sakai and well documented.
    • Example: Use preferences saved within Sakai. If not set, default to user browser preferences. If not set, default to Tomcat locale settings. If not set, default to operating system locale settings. If not set, default to default locale.

i18n goals:

  1. Dynamic editing of translations
  2. Display names for tools or other repeated UI texts should be translated once and shared across the whole Sakai release
  • No labels

2 Comments

  1. For #3, I'd be inclined to urge that there should be a common, consistent way to handle translations across all functionality. This can be understood as a help to developers, in that they don't have to invent their own system, and it should also minimize the documentation burden. There may be occasions where full consistency can't be an ironclad requirement, but that should still be the goal, and exceptions should be relatively rare.

    In general, I think the strategy of letting each developer do what they want, but then following up by hounding them to explain what they've done, is creating more work on both ends.

    I'm not sure I understand #4, but that may be my technical ignorance getting in the way.

    1. For #3, this may not be possible with historical 2.x. I'm not the one to answer about 3.x.

       For #4, see KNL-267 for an example in 2.7 or later.