Give us contact

Do you prefer to ask us directly?

Call us +420 605 203 938 (the Czech Republic)

or use this contacts

AyMINE

Related links


FI - Finance Management

Strings and translations

AyMINE framework manages strings and their translations separately for backend and frontend.

Back-end translation

Each module has its own list of translation stored in the file

/<module>/settings/m_<module>Lang.json

File contains translation for all languages in the data structure:

<lang_code> {
   "string_name":"string translation",
   "string_object":{
      "string_name":"string translation",
   }
}

Example presentes two language structures that are supported – single string and object with translations. Object is recomended for pages and other objects where more string is used. Objects is loaded at onces and provide fast access to all strings in the object.

Using independent string

Function interface for work with strings is the LangProvider object. Look at the description of the module in the source code documentation. The most common method to get the translation is:

LangProvider::getString(<module>, <string name>, optional <language>)

Object with strings

Object with translations should be loaded prior it usage to get access and then strings are available by methods from object:

Get translation object:

$translationObject = langProvider::getPageDataTrans(<modul>, <object name>, optional <language>);

Method returs array(!) with translations. However, fields are available using the object method trans:

$translated = $translationObject->trans(<string name>)

Preloading the back-end translation

Back-end translation is pre-loaded to the database during the module instalation to the running environment. They are preloaded in bulk or using a method Load back-end translatation (see the list of modules).

Front-end translations

Front-end application uses translation pre-loaded to the client. Each module and each object could use as many translation files, as necessary. Translation for each object is searched in the translation string in order how they are defined in the object definition (object jsonc definition) in the section data -> about -> langModules.

Each language has separate files stored in the separate directories -> langs -> -> .json . Translation strings are always single string, there is no any more complex data structure.

Hint strings

Hint strings are visible when used touch or move cursor over the button.

Hint strings for views are visible on the view name. They are stored as a string with view name and _hint appendix after the name.

Hint for field is store similarly – in the string with name of the field name and _hint after that

Sometimes it is important to put information somewhere, where it is not supported by application e.g. regular text in the object clip. Look at the example with information string about the object problems.

Information help coul be placed to the string directly with the basic text but with html formatting:
` “”:” … hint …

",

Important: Do not use paragraph in the hint text. However, line breaks
, marks and other in-line marks could be used.

Help files

Back-end generated error messages

Error messages are translated by client. Server always returns only error codes, no translated strings.

Functions that use complex return messages should not use error messages for them. It shall be processes by the client method window.message(retAttr).