admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Locale -> Translation

Browse Source
This commit is contained in:
John Cardinal
2020-03-06 19:36:36 +00:00
parent 884c834b3d
commit a234b3531d
58 changed files with 540 additions and 569 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
devdocs/specs/core-generator.txt
View File

@@ -87,7 +87,7 @@ DeliverNotifications (techs)
/// foreach NotifyEventRecord it adds a NotificationListInfo
/// for each open delivery window for each subscriber to that event
/// As it Processes each deliverable notification it formats it to users
/// locale and preferences for size etc and keeps track of the address and
/// translation and preferences for size etc and keeps track of the address and
/// delivery type.
///
///

2
devdocs/specs/core-import-v7.txt
View File

@@ -73,7 +73,7 @@ NOTES FOR DOCS
- Only an empty database is supported for import
- Only one shot import, can't import again later
- LOCALES
- MUST be a default locale set before import because new raven keys will be added to imported v7 locale using the default locale only
- MUST be a default translation set before import because new raven keys will be added to imported v7 translation using the default translation only
- IMPORTED USERS
- In order to ensure security imported users are not imported ready to login but rather must be edited individually after import:
- All users are imported with Active status set to false and must be individually edited and set to Active=true as required

4
devdocs/specs/core-list-graph-datatable-filter-sort.txt
View File

@@ -153,7 +153,7 @@ Two types of filters Named or Default:
- This is a client issue, Server doesn't care what the filters are called adn has no special processing for default filters
Named filters can be made public or personal. If public then all users with rights to that object can see them, personal are always only personal.
Filter is constructed from an FILTEROPTIONS object fetched from the server list route that has a list type name which is unique to that list route
and also lists all the fields filterable, their type and the locale key to display it
and also lists all the fields filterable, their type and the translation key to display it
- e.g.: {ListKey:"widget",fields:[{fld:"name",lt:"WidgetName",type:"text"},{fld:"dollarAmount",lt:"WidgetDollarAmount",type:"currency"}]}
- List key
Certain types have extended abilities, for example dates have the classic floating AyaNova date ranges pre-defined or specific dates
@@ -186,7 +186,7 @@ Upon user selecting a filter to use the list query string has the regular paging
--------------------------------------------------------
NOTES ABOUT WHY I DID THE FILTEROPTIONS LIKE I DID:
//Need a collection of fields and types and locale keys for
//Need a collection of fields and types and translation keys for
// - Client fetching filteroptions via list class
// - Just a static list of items localized and sent to the client
// - DataFilter validation via list class

4
devdocs/specs/core-main-grids.txt
View File

@@ -7,7 +7,7 @@ Proposed system is a hybrid grid system that has two modes to take into account
- In this mode only one column shows and it's formatted according to the Display Format Template
- DisplayFormatTemplate is specd in the core-display-format-template-system.txt doc
- So the user chooses which columns to show in a small factor themselves, default is name only or equivalent
- As the client already does all the presentation and locale formatting it will also handle mini column concatenation
- As the client already does all the presentation and translation formatting it will also handle mini column concatenation
- The server's responsibility for mini is to use the mini format template which may well have different columns defined than the full
- Return the data just the same as for the wide template but it's very likely different data
@@ -62,7 +62,7 @@ Server
- Optional: ID value (if the object is openable **** MUST CHECK RIGHTS ALSO HERE **** then this is the id to open for the client to put a hyperlink on that column)
- To save bandwidth abbreviations are used in the column definitions:
- ColumnsJSON=@"""columns"":[ {""cm"":""Widget"",""dt"":""text"",""ay"":"+ AyaType.Widget.ToString()+ "}]";
- cm=column name locale key, dt=AyDataType, ay=AyaType to open on click of that column field (optional, not present if not openable)
- cm=column name translation key, dt=AyDataType, ay=AyaType to open on click of that column field (optional, not present if not openable)
- rid flagged column in each row is *ALWAYS* the rowID column specified in objectfields with it's sql attributes
- For example (wide list):
data:{

2
devdocs/specs/core-roles.txt
View File

@@ -259,7 +259,7 @@ BizAdminLimited | BizAdminFull | DispatchLimited | DispatchFull | InventoryLimit
- Schedule
- Memos
- Reminders
- Locale settings for User
- Translation settings for User
- Set login and password
- Notification subscriptions

2
devdocs/specs/core-testing.txt
View File

@@ -13,4 +13,4 @@ FRONT-END
- Integration tests that excercise the front end and ensure things appear where they are supposed to given certain tasks
- Ideally it would be able to run a set of business tasks against the UI and confirm at each point like make a rando customer and then a workorder and on
- Something that we can leave running for a long period of time to verify load and no leaks
- MUST cause all locale keys required *anywhere* in the UI to be requested one way or another so that I get a valid list of used keys so I can winnow out the unused ones
- MUST cause all translation keys required *anywhere* in the UI to be requested one way or another so that I get a valid list of used keys so I can winnow out the unused ones

52
devdocs/specs/core-localization.txt → devdocs/specs/core-translation.txt
View File

@@ -1,52 +1,52 @@
# Localization specifications
# Translation specifications
REQUIREMENTS
- ROLE RIGHTS: BizAdminFull only can edit. BizAdminLimited can view but not change
- CENTRAL LOCALE EDIT FORM
- End user customizes localizations from a central location with a kick ass search and change ability
- We will *not* support localization changes form by form as in v7 but only from central location
- 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* localization presentation locally, only exception is the server ops logs
- 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 locales that did not come with AyaNova 7
- Dump needs to check if the "stock" locale has been edited or not before exporting
- 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 locale 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 locales to migrate to the new key values
- Two kinds of locales: Stock and Custom.
- Stock locales are stored in db and not user editable
- STock locale names are whatever the international name for that locale is like "esp" or "fr" etc
- Custom locales are stored in the database and are user customizable
- 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 locales
- GET ROUTE that provides a pick list of translations
- GET ROUTE that returns all key value pairs when requested for a specific locale
- 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 locale and specific list of locale keys provided
- 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 locale and updates the current values in db from the provided list
- if locale name key provided is one of our stock ones then it errors out as you can't change the stock locales
- if locale doesn't exist in db errors out
- 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 locale duplicated from an existing locale and copies all the values from the existing locale
- Post object {sourceLocale:"English", newLocale:"MyLocale"}
- 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 locale
- This is also how you rename a translation
- DELETE ROUTE for deleting any non-stock locale
- Can't delete current DB default locale (specfic error)
- Users of that locale will be reset to current DB default locale
- 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
@@ -91,7 +91,7 @@ CLIENT
- 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 locale or the locale name and so it needs to check via the user account what the locale is
- 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

2
devdocs/specs/core-ui-design.txt
View File

@@ -43,7 +43,7 @@ Requirements
- MEMOS (for user)
- SCHEDULE MARKERS (list for user, convenience extra so don't need to hunt around on calendar)
- SETTINGS
- User locale settings
- User translation settings
- Any other user specific settings that the User can control (and sb able to control more than in v7 if it doesn't affect anyone else)
- Change login?
- notification subscriptions