# Translation specifications


REQUIREMENTS
    - ROLE RIGHTS: BizAdminFull only can edit.  BizAdminLimited can view but not change
    - CENTRAL translation EDIT FORM
    - End user customizes Translations from a central location with a kick ass search and change ability
    - We will *not* support Translation changes form by form as in v7 but only from central location
        - Faster to code TTM
        - User doesn't think they are only changing it on one form only
        - Some forms don't have all the related keys on them (i.e. a list will show "Widgets" even though the edit form never shows that string)
    - Client handles *ALL* Translation presentation locally, only exception is the server ops logs
        - This saves bandwidth and hassle and leaves presentation to the client where it belongs (was a source of trouble in v7)        
    - Keys are text, human readable and as short as possible
    - Not numeric ID's for these, strictly textual
    - values may have substitution tokens in them for certain things
    - DataDump plugin will export and import any custom translations that did not come with AyaNova 7
        - Dump needs to check if the "stock" translation has been edited or not before exporting
        - Only edited ones are exported
        - For example if someone edited the Spanish translation then it would dump as "Spanish-Custom" (or whatever the word for custom is in that language) so as not to interfere with our stock Built in Spanish in Raven               
        - The documented renaming (below) will need to be automated during import of v7 stock translations to migrate to the new key values
    - Two kinds of translations: Stock and Custom.
        - Stock translations are stored in db and not user editable
            - STock translation names are whatever the international name for that translation is like "esp" or "fr" etc           
        - Custom translations are stored in the database and are user customizable

    ROUTES
    - GET ROUTE that provides a pick list of translations

    - GET ROUTE that returns all key value pairs when requested for a specific translation
        - This one is for editing purposes or for export to disk

    - GET ROUTE that returns a list of specific key value pairs for a requested translation and specific list of translation keys provided
        - This one is for day to day ops and will be called on any client opening a new area of UI they have not previously opened
   
    - PUT ROUTE that accepts a list of key value pairs and a specific translation and updates the current values in db from the provided list
        - if translation name key provided is one of our stock ones then it errors out as you can't change the stock translations
        - if translation doesn't exist in db errors out
        - biz full rights only 

    - POST ROUTE that creates a new translation duplicated from an existing translation and copies all the values from the existing translation
        - Post object {sourcetranslation:"English", newtranslation:"Mytranslation"}
        - Errors if already exists with that name
        - Sets it to stock=false so it can be edited
        - This is also how you rename a translation

    - DELETE ROUTE for deleting any non-stock translation
        - Can't delete current DB default translation (specfic error)        
        - Users of that translation will be reset to current DB default translation
 


 
CHANGES MADE TO KEYS FROM v7
     
    - Replaced all [.Label.] with [.]
    - Replaced all ["O.] with ["] this needs to be a case sensitive change!!!
- Removed duplicate key [WorkorderService.CloseByDate] that resulted from last change of O. (the first one between workorderservice and workorderstatus)
    - Replaced all [.ToolBar.] with [.]
    - Replaced all [.Toolbar.] with [.]
    - Replaced all [.Go.] with [.]
    - Replaced all [.Command.] with [.]
- Removed duplicate key created by last operation: [UI.Search] (removed second longer one that refers to database)
    - Replaced all [.Error.] with [.]
    - Replaced all [.Object.] with [.]
    - Replaced all ["UI.] with ["] (and removed exact dupe keys created as a result)
    - Replaced all [.] with []
- Removed dupe WorkorderItemOutsideService (removed the one with the longest value)
    - Replaced all ["AddressAddress"] with ["Address"]
    - Replaced all ["ContactPhoneContactPhone"] with ["ContactPhone"]
    - Replaced all ["ContactPhonePhone"] with ["ContactPhone"]
    - Replaced all ["PurchaseOrderPurchaseOrder"] with ["PurchaseOrder"]
    - Replaced all ["WorkorderItemMiscExpenseExpense"] with ["WorkorderItemMiscExpense"]
    - Replaced all ["WorkorderItemTravelTravel"] with ["WorkorderItemTravel"]

Note: still some dupes but...fuck it
   



- TODO: Some of the keys are new and not translated from English, when all is done and the keys that will be carried forward are determined, check for untranslated ones
    - Use Google translate to get a rough approximation.
        - A technique to get a good translation would be to try various synonyms out and try to zero in on the commonality in translation to ensure a word is not being completely misunderstood to get a better translation
        - I.E. if different forms of the phrase result in similar words in the other language then it's probably Gucci


CLIENT
    - Client fetches localized text on an as required basis form by form and caches it locally until cache is invalidated
    - Cache invalidated by either a timeout or possibly receiving a message from the server.
    - Open an edit form 
        - client checks local cache (do I have the values for the list of required keys??)
            - YES: just use it
            - NO: Send a list of keys to the server along with the user id that are required for this form and get back the LT, put it in the cache
                - User id required because someone might edit their translation or the translation name and so it needs to check via the user account what the translation is

This way there is no wasted space at the client caching stuff that will never be used

CHANGES:
    - If the text is changed at the server then a notification should occur for clients using that local to invalidate their cache
        - Although, that would be a pretty rare event so...maybe not so much, a logout could clear the cache or a login I guess



