There are two concepts for translations in Omega365. Translations and T-Tables. T-Tables are used for translating content inside tables. This Article does not describe T-Tables, see separate article.
EXEC dbo.afThrow 'Hello world!'Result: Hello world!
-- Use up to 3 paramaters. Parameters are not translated. EXEC dbo.afThrow 'There are %P1 apples in a dozen',@P1 = 12Result: There are 12 apples in a dozen
-- The @Object allows for using the same base string with different translations EXEC dbo.afThrow 'Hello world!', 'stbl_Translate_Strings' Result: Hei verden! EXEC dbo.afThrow 'Hello world!', 'sstp_Translate_PublishDBObjects' Result: heisann verden!
First go to my-profile app and set the language you want to translate. Then, add &translate=true to the URL of any app to enter Translate mode.
Try Clear localized strings Cache and then Clear localized strings. See screenshot.
EXEC dbo.sstp_Translate_PublishAllDBObjects EXEC dbo.sstp_Translate_UpdateTranslationsAllApps EXEC dbo.sstp_Translate_UpdateTranslationsAppframeScripts
Also Clear localized strings Cache and then Clear localized strings. See screenshot.
Here are some things to try:
In MSSMS you can right click a user an set a default language. Note that there are both Bokmal and Norwegian in SQL server, in general the Norwegian is the correct one.
ALTER USER [Audun] WITH DEFAULT_LANGUAGE = English -- or ALTER USER [Audun] WITH DEFAULT_LANGUAGE = Norwegian
Appframe requires all strings to be translated to be wrapped in in keywords so that Appframe is able to detect the translation and add it to the table of translations. The examples above shows the different ways to do that in js, html and sql.
All parsing and identifing basestrings are done by stored procedures (see Regeneration of basestrings for names of procs).
The object where Basestring is found (for example a trigger or a app) is part of basestrings Unique Index. It therefor possible to have different translations for the same word in different apps/objects.
The idea behind Verifid field is that new basestrings that are found will be added and verified set to NULL. A human needs to go in and verify new basestrings as they come to ensure propper translations. When clicking "Auto suggest" appframe has some logic to aid with suggesting translations on non-verified basestrings (see sstp_Translate_UpdateStringsFromRanking explenation).
Regeneration of basestrings is done by adding basestrings that are missing and deleting basestrings that are not used anymore to the table stbl_Translate_Strings.
Regenerate basestrings is generally safe to do as many times one may want.
sstp_WebSiteCMS_CopyArticle, that executes
sstp_Translate_PublishDBObject. This will only create basestring on developer database not on my.omega
EXEC dbo.sstp_Translate_UpdateTranslationsForApp 'Pims365/workflow-item'
sstp_Translate_PublishDBObject, that proc executes
sstp_Translate_UpdateTranslationsForApp. This will only create basestring on developer database not on my.omega
EXEC dbo.sstp_Translate_PublishDBObject 'stbl_Translate_Strings_ITrig'
||Stores basestrings, see above for how this table is populated|
||Stores the actual Translations of basestrings|
||Languages in use|
||View used by app
||Used by framework to populate cache after cache has been cleared. See 4. in screenshot below or "Clear Loclized Cache" in /|
||Used by code module
||Used internally by
||Synonym for sstp_Translate_ThrowException|
||Used by framework in &Translate=True mode to add translations|
||Not in use anymore.|
||This proc checks that language on sql server user is in sync with what is set in Pims if not it generates Alter User statement. Proc is executed from _Persons_Utrig. See Troubleshooting number 3 and Set language of user on SQL server.|
||Used interally by Translations to find the actual basestring in apps and db-objects. Keywords are stored here.|
After strings are added to