Skip to end of metadata
Go to start of metadata

Survey Questions

  1. What languages do you need to support?
    1. Will you need support for more than one language at the same time?
  2. In the past the focus has started on maintenance documents which are generally automatically generated by the system. However it's expected that support for transactional documents will be required as well. Seeing that the coding of these is initially done in english; what is the expected process for localization? Would there be multiple copies, the original and the local created by some hand or batch process? Would there be some sort of translation done as part of the interface? Other?
  3. What is the scope of an internationalized Rice in your view?
    1. Is this just end user facing items?
    2. Does this include administrative items as well, screens, reports, etc.?
    3. Thinking of developers, should exception messages, code notes, etc. be considered as well?
  4. With your current internationalized system, what tools and scope related to the above do they provide?

Requirements

Background Information

Rice Roadmap Items

KRRM-82 - Data cannot be retrieved due to an unexpected error

 

  • No labels

1 Comment

  1. Survey Questions Answers from NWU

    1. What languages do you need to support? - Afrikaans AND English and potentially a third language like Tswana
      1. Will you need support for more than one language at the same time? - Yes, al 3 language will be required in one running instance of the system
    1. In the past the focus has started on maintenance documents which are generally automatically generated by the system. However it's expected that support for transactional documents will be required as well. Seeing that the coding of these is initially done in english; what is the expected process for localization? Would there be multiple copies, the original and the local created by some hand or batch process? Would there be some sort of translation done as part of the interface? Other? -
      1. I don't expect maintenance documents or transactional documents to be handled differently for internationalization, no multiple copies, no batch process and no translation.
      1. The business objects however should change depending on the type of data to capture more than one language for certain fields such as titles, names ie. courses and programs and descriptions. This should already be available in the rice framework as you only need to move those fields to a subclass with a one-to-many relationship.
    1. What is the scope of an internationalized Rice in your view?
      1. Is this just end user facing items? All screens, reports, system generated emails, etc visible to students, academic and admin staff.  Any text, status codes etc whether its student facing or not, everything needs to be multilingual
      2. Does this include administrative items as well, screens, reports, etc.? All general admin except system admin used only by IT staff.
      3. Thinking of developers, should exception messages, code notes, etc. be considered as well? - No, developers only need English, all code notes java docs should only be in English.
    2. With your current internationalized system, what tools and scope related to the above do they provide? -
      1. Link a preferred system and correspondence language to a user used in system generated emails and documents.
      1. Toggle/droplist to allow user to select language on screen, override preferred system language
      1. Toggle/droplist to allow user to select language for generation of a specific report or document.
        Note: Basically there are two different types of messages that needs to be displayed to the end user based on his/her preferred language.

    1. Messages displayed on the screen and on reports as headings, titles, tooltips etc. This is the easy one and for this we use message catalogs.

    2. Data descriptions and names ie course names, country names, campus names etc should be captured in both languages.  Database and system design caters for this and it's easy to add a third or forth language - an initial process will have to be done to create message catalogs for the newly added language and to translate all the data in the database for the language.  THis however is not handle by the system and would be a separate process