Translations

[Ghesselink]

Brief summary of current structure;
The script compiles .po files into .mo files and stores them in the cache, but only if the cache is not already populated. Otherwise, the translations are retrieved directly from the cache and made available on the server, with the language preference stored in a cookie on the frontend and translations passed to HTML via (server.py) render_template.

Todo

• we have to disable caching, we cannot cache based on translations alone because the .md files can also change, we'll implement caching later on using a separate reverse proxy
• create .mo files in create_resources for easy get started
• create .mo files using multiple threads
• When there is no translation, don't show an empty aside but rather show that there are no translations for this language and a link how to contribute.
• Generate the language-selector options from the dictionary in Python, and remove the dict in JS (it's not used)
• Chinese Simplified has a space, this most likely brakes the classname, it's the only one. (but this is hopefully solved by autogenerating the options.

[Ghesselink]

To do; styling similar as entity.html

[Ghesselink]

To do; styling similar as entity.html

[Ghesselink]

c&p from Ghesselink#1

Some changes that I needed to get things running:

    Support windows (msgfmt -> babel, utf-8, ...)
    eliminated the need for page reload to switch language
    tweaked style
    updated some defaults to point to the submodule

Todo

    we have to disable caching, we cannot cache based on translations alone because the .md files can also change, we'll implement caching later on using a separate reverse proxy
    create .mo files in create_resources for easy get started
    create .mo files using multiple threads
    When there is no translation, don't show an empty aside but rather show that there are no translations for this language and a link how to contribute.
    Generate the language-selector options from the dictionary in Python, and remove the dict in JS (it's not used)
    Chinese Simplified has a space, this most likely brakes the classname, it's the only one. (but this is hopefully solved by autogenerating the options.

Questions

    I really don't understand load_original() this seems really inefficient and I don't know what it does. Related to that I don't understand why we have both TRANSLATIONS_DIR and CROWDIN_REPO_DIR, I don't know what to initialize these to. I see there is only one submodule initialized.

Support windows (msgfmt -> babel, utf-8, ...)

I'm sorry, I didn't consider that

we have to disable caching, we cannot cache based on translations alone because the .md files can also change, we'll implement caching later on using a separate reverse proxy
create .mo files in create_resources for easy get started
create .mo files using multiple threads

Does this mean we'll still translate the entire html and load only the 'active' translation, or do we then just create .mo files and do the translation on request (when loading the page)? In that case, we can still cache these .mo files based on newly incoming translations in the translate repository

I really don't understand load_original() this seems really inefficient and I don't know what it does

I'm having another look at it, but load_original() is redundant for entities and properties; I've used it for type objects. More specifically, for type values. For example (IfcWallType).

So load_original is used to get the original values here and afterwards further processed in the type html.https://github.com/Ghesselink/IFC4.3.x-development/blob/944fdc00c861fe6f829c19d2424f48cb96d2c7bb/code/templates/type.html#L64-L74

I've had some issues with loading these from the .md locally. Furthermore, this way we're completed sure that the translated text is the same as the original. However, as you mentioned, when we move away from caching based on translations and track changes in the md file too this will be redundant.

I don't understand why we have both TRANSLATIONS_DIR and CROWDIN_REPO_DIR, I don't know what to initialize these to.

It's a bit of a mix with terminology sometimes. 'Translations' can mean a couple of things now already;

• The repository containing the translations -> CROWDIN_REPO_DIR
• The actual translation process of IFC entities, properties and types (+ type values).
• The place where translations are being stored -> TRANSLATIONS_DIR
• This branch and when referencing to this project ..

Perhaps we can better rename this to cached_translations or similar, and store the http responses in redis (?)

[aothms]

Does this mean we'll still translate the entire html and load only the 'active' translation, or do we then just create .mo files and do the translation on request (when loading the page)?

I would say create all .mo files at startup and when there are changes to the translations. Most likely in poller.py

I still don't really understand the load_original (and how it interacts with caching). Could you give some example values and how it's not possible to get these from the compiled .mo?

The place where translations are being stored

You mean the html cache?

fyi caching is easy to do for ex in nginx https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/

Let me know how you think we can advance on finalizing this?