104 lines
6.4 KiB
Plaintext
104 lines
6.4 KiB
Plaintext
# 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
|
|
|
|
|
|
|