Locale -> Translation
This commit is contained in:
@@ -12,7 +12,7 @@ Error messages / Numbers
|
||||
- Look for English text in all the messages so far and see if can be localized even crudely by google translate and do so
|
||||
- Make sure error numbers have a consistent system and don't conflict, I think there are two sets of error numbers, there should only be one
|
||||
- Make sure Every error has a number and that is documented in the manual
|
||||
- Locale keys for error numbers?? i.e. E1000, "blah blah error 1000"
|
||||
- Translation keys for error numbers?? i.e. E1000, "blah blah error 1000"
|
||||
|
||||
C# code convention:
|
||||
All names are PascalCaseOnly with the following two exceptions:
|
||||
@@ -24,8 +24,8 @@ C# code convention:
|
||||
DATES, TIMES, TIMESTAMPS - All dates and times sent or retrieved from the REST interface must be in UTC / GMT time zone.
|
||||
It is the client's responsibility to display and accept dates in local format but interaction with the server is in UTC only.
|
||||
|
||||
Localized text - All text prsented by the server will be a locale key only and it is the clients responsibility to display in local text format with the exception of:
|
||||
- Ops logs, Metrics, event logs: these items and any other future pre-generated text items will be localized at the server according to the logged in users' locale
|
||||
Localized text - All text prsented by the server will be a translation key only and it is the clients responsibility to display in local text format with the exception of:
|
||||
- Ops logs, Metrics, event logs: these items and any other future pre-generated text items will be localized at the server according to the logged in users' translation
|
||||
|
||||
|
||||
JAVASCRIPT
|
||||
|
||||
@@ -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.
|
||||
///
|
||||
///
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:{
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -4,6 +4,8 @@
|
||||
|
||||
## IMMEDIATE ITEMS
|
||||
|
||||
TODO: DataDump plugin make sure locale export json files are named "translation" instead as raven only sees "translation" when importing
|
||||
|
||||
|
||||
TODO: BizRoles.cs seems to get hammered on every single request, is it efficient?
|
||||
- Why is it not cached in some way?
|
||||
@@ -21,8 +23,8 @@ TODO: 2019-06-07 10:47:57.8894|WARN|Microsoft.AspNetCore.Cors.Infrastructure.Cor
|
||||
Configure the policy by listing individual origins if credentials needs to be supported.
|
||||
|
||||
TODO: "Client" -> "Customer " all languages but english need translated whatever was translated for "Client" text to whatever is now that languages "Customer" text (did english only for dev purposes)
|
||||
TODO: "Service workorders" now "workorders" do for non english locales, keys changed are: GlobalWorkorderNumberStartSeed, WorkorderServiceTemplate, GlobalUseInventoryDescription, GlobalUnitNameDisplayFormatsDescription, WorkorderServiceList
|
||||
- Also a shit ton more todo in all locales including english - just search for Service workorder case insensitive to see a bunch (in english anyway)
|
||||
TODO: "Service workorders" now "workorders" do for non english translations, keys changed are: GlobalWorkorderNumberStartSeed, WorkorderServiceTemplate, GlobalUseInventoryDescription, GlobalUnitNameDisplayFormatsDescription, WorkorderServiceList
|
||||
- Also a shit ton more todo in all translations including english - just search for Service workorder case insensitive to see a bunch (in english anyway)
|
||||
|
||||
TODO: Need to burn test for memory leaks
|
||||
|
||||
@@ -64,7 +66,7 @@ TODO: Two kinds of mass fetch records in RAVEN
|
||||
- ACTION required:
|
||||
- Make sure the server supports this
|
||||
|
||||
TODO: locale cjkindex, no way to set this value currently
|
||||
TODO: translation cjkindex, no way to set this value currently
|
||||
|
||||
TODO: Licensing - make sure tech type use license works properly: a tech license is consumed if a user has **any one** of the four roles of TechFull, TechLimited, SubcontractorFull, SubcontractorLimited
|
||||
### TODO FILTER ISSUE: SEE integration tests search for BUGBUG there are two tests failing in DataFilterFilteringLists tests that might be DST related
|
||||
@@ -82,7 +84,7 @@ TODO: Need client docs at server end just for client user
|
||||
- I just don't want the hassle of setting up another build process for client docs and folders and shit right now
|
||||
|
||||
TODO: UNLOCALIZED TEXT
|
||||
- Look for old locale text keys that were not translated, there are more than a few keys that were added later to v7 and never translated out of english.
|
||||
- Look for old translation text keys that were not translated, there are more than a few keys that were added later to v7 and never translated out of english.
|
||||
- Some may never be used so be careful about this.
|
||||
- Unused keys won't be taking up any bandwidth so maybe this is a non-issue but you never know if I might need something in future as well so...tricky, maybe this is a 2.0 thing
|
||||
|
||||
@@ -217,7 +219,7 @@ Once I can make the client I need to get into that and make the shell and initia
|
||||
- Login , logout
|
||||
- License
|
||||
- Security / rights
|
||||
- See localized text / change locale
|
||||
- See localized text / change translation
|
||||
|
||||
later
|
||||
- Widget CRUD and lists
|
||||
@@ -269,12 +271,12 @@ MISC FUTURE ITEMS NOT SURE ABOUT THAT CAME UP DURING CODING / TESTING
|
||||
- LOCALIZED TEXT
|
||||
- Localized text keys would be nice if they are understandable as is for API direct users so you don't need to be in the client to understand
|
||||
what's happening
|
||||
- Need a locale indepedent locale so that server errors without a corresponding user are localized to default english
|
||||
- Also maybe a locale can be chosen at the server for error messages since we'll go by code numbers anyway.
|
||||
- Need a translation indepedent translation so that server errors without a corresponding user are localized to default english
|
||||
- Also maybe a translation can be chosen at the server for error messages since we'll go by code numbers anyway.
|
||||
- Starting to get to the point where I'll need this, i.e. error messages and logs that are part of core ops but need to be displayed in the UI
|
||||
- Need to go through the api and find all the plain text messages returned and convert to locale text keys
|
||||
- Need to go through the api and find all the plain text messages returned and convert to translation text keys
|
||||
- Ensure every error message has an error number of one kind or another and that they are not conflicted and easy to sort out if coming from server or api or etc
|
||||
- Need to suck out our paid for translations and convert them into new locale text format
|
||||
- Need to suck out our paid for translations and convert them into new translation text format
|
||||
- DataDump??
|
||||
|
||||
- REPORTING
|
||||
|
||||
@@ -576,5 +576,5 @@ Use the credentials specified for postgres which is username postgres and passwo
|
||||
|
||||
|
||||
TRANSLATIONS / TRANSLATE / LOCALIZATION / LOCALE
|
||||
Microsoft handy dandy product locale search database site: https://www.microsoft.com/en-us/language/Search
|
||||
Microsoft handy dandy product translation search database site: https://www.microsoft.com/en-us/language/Search
|
||||
Google translate to verify: https://translate.google.com/
|
||||
Reference in New Issue
Block a user