Skycultures: Transifex amount of work is huge

[axd1967]

Current amount of untranslated strings for stellarium-skyultures: 3452

It would be more doable to split the skycultures into separate resources; for example, I'm used to Western skycultures, but am reluctant to translate Chinese, Arab etc into Dutch because I'm not sure the translation will be correct.

Also, some words probably cannot and should not be translated (I guess "Bubup" is an example). Another example that I am unable to translate is "Dōngcìjiàng zēng III"; this requires a Dutch translator fluent in Chinese.

Or maybe introduce some way to filter by sky culture? Transifex seems to offer tags, labels, keys? So I could focus on e.g. translation of Western to Dutch.

[gzotti]

Translate what you want and can do, and don't what you don't want. Unfortunately, several Skyculture authors did not add English translations to non-Western cultures. We do not have the resources to change that legacy. Untranslated words are still shown. Untranslated, until somebody can do it.

[axd1967]

But can't this be partitioned into separate Transifex resources? Here is a part of the current partitioning of resources:

Here, all sky cultures are in one single resource.

The idea would be to make a separate resource for each skyculture. E.g.

stellarium-skyculture-western
stellarium-skyculture-western-Rey
stellarium-skyculture-western-Hlad
stellarium-skyculture-western-Sky-and-Telescope
stellarium-skyculture-Tukano
stellarium-skyculture-Siberian
stellarium-skyculture-Sami
...

(see https://github.com/Stellarium/stellarium/tree/master/skycultures)

likewise for planetary features: why not partition off per body?

This increases the amount of resources, but encourages translators because they will have to face smaller amounts of strings to translate (although the total remains the same). Also, some translators might be more specialised (eg Moon features).

[gzotti]

TBH the planetary features need no translation for probably all languages which use Latin characters. I would rather even like to have a flag that says "use original", to keep the download package smaller.

[alex-w]

But can't this be partitioned into separate Transifex resources? Here is a part of the current partitioning of resources:

OK, you are propose remove 4 resources and add 103 resources with many doubles (please explain why translators should translate one word many times?). Of course you may explain why we should create an over 100 copies of translators and update all of them when user changed language - for example we need create 45 copies of translators for planetary nomenclature and update all of them when user is changed language. Of course when new celestial body will have named features, or new landscape, or new sky culture we'll need refactored spaghetti of translators. And we should add many checks to each translators to avoid crashes, because user may have custom landscape or sky culture and of course your idea will give us perfect crashes on this objects. Or you proposes to remove support any landscapes and sky cultures, which storing not in repository? Or may be adding additional 100 copies of translators for each users landscape? I hope you can explain to users also why stellarium will use in this case 1GB RAM at startup.

This increases the amount of resources, but encourages translators because they will have to face smaller amounts of strings to translate (although the total remains the same).

Total strings for translation will be increased.

Alex, please explain why I should make life worse for 387 peoples just because you "cannot translate the Moon's nomenclature"?

[axd1967]

The strings added in #1343 add an interesting dimension to this issue: some strings should not be translated (eg Roman month names, but probably only for European languages - see also https://github.com/Stellarium/stellarium/pull/1343#issuecomment-751373507), while other strings need translator skills for two languages (eg Icelandic -> Dutch), where usually translators only needed to translate English -> Dutch.

The foreign strings are easily skipped, with the risk of also skipping other strings that DO need to be translated.

[gzotti]

Be certain that some strings in the Calendars plugin will be changed in the future. More calendars, better harmonisation etc. This is work in progress. And yes, translation in cultural topics is more difficult than just scientific vocabulary. This will be a major challenge when we at some later date (no date given here!) dive further into skycultures with non-European character sets and user language dependent transliteration systems.

The translations of foreign name strings in this context is generally not recommended, although spelling may depend on user language. You could of course translate e.g. Icelandic weekday names to Dutch, but is that useful when the "well-known" calendars have translated weekday names? I must leave this decision to the responsible language team heads (reviewers) of the translator teams.

[axd1967]

I'm afraid the amount of untranslatable strings is raising due to new Calendars (and probably due to forthcoming skycultures).

Please consider splitting off Calendar and Skycultures into separate Transifex resources. Can other translators please suggest how they cope with this amount of strings?

[alex-w]

Maybe I just should remove all Dutch translations (and Dutch language) from Transifex to resolve your "problem"?

[gzotti]

If you don't translate it, maybe somebody else does. If not, users will be confined to English, or whatever original language was used in this context. I was asked to make Latin strings "translatable". These should not be translated in terms of language, but allow transliteration into other character systems. My recommendation for the calendar strings: Just copy all those strings untranslated if your writing system is related to Latin-1.

[axd1967]

for_wishlist

[axd1967]

To recap, the problem is that for example 0.21 contains a small number of untranslated strings in the Almagest culture, which is a shame because this is a big boon for Stellarium. But the amount of untranslated strings over all skycultures is huge and is frankly discouraging:

It would be great to be able to isolate the Almagest strings, and for a short while I hoped that Transifex tags could have helped. The idea would have been for the translator to filter on a tag (eg "almagest"), which would immensely simplify his/her translation job.

I looked a bit in the Make system but could not yet isolate a good way where such tags could be injected somewhere in the process. Maybe someone has an idea?

Maybe txjs-cli could be used in the CI pipeline?

(Please keep the issue open, I'm sure we can find a solution; otherwise it will be overlooked as it is not logical to look for issues... in closed issues.)

for_wishlist

[gzotti]

Don't search for ways to avoid translation. The only solution I can see: translate! Usually the strings come in blocks like 280 from Almagest, 1400 from Chinese, 150 from Belarus, etc.

[alex-w]

This is incredible! Alex, please read the docs for Transifex about filtering the data! Please, do not invent the problems, where is not problem!

Hint: please try type the text occurrence:almagest in the filters input box for stellarium-skycultures section or developer_notes:Mercury for stellarium-planetary-features section

[axd1967]

owww! that would be great, thanks!

(didn't notice the "More" tab...Transifex has some small UI issues...)

for anyone interested, see https://docs.transifex.com/translation/translating-with-the-web-editor#available-filters

[axd1967]

Transifex seems to allow to further subdivide string pools using concepts such as "occurence", "key", "tags". Maybe these can help in subdividing the translation tasks.

Also, translators now need to be specialised in (astro)geology, geography, astronomy, culture, ... This is not doable.

[axd1967]

@alex-w @gzotti please help: how can I exclude strings from "src/translations_regions.h"?

because I suspect that this file is GENERATED, and therefore might benefit from additional Transifex tagging support.

[gzotti]

If you cannot translate it, just don't. These strings are part of the main package and therefore cannot be split off.

[axd1967]

I think the solution lurks here:

• https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
• https://github.com/Stellarium/stellarium/blob/0b047c7b06dd73c18d6012079ad60f7cba02539e/src/core/StelTranslator.hpp#L66-L68

how can one know what contexts exist?

note for the interested: qc_ seems to do this - it allows to define contexts: https://github.com/Stellarium/stellarium/blob/0b047c7b06dd73c18d6012079ad60f7cba02539e/src/core/StelObject.cpp#L691

I'm not sure what context does, but I wonder if following is good use of context - shouldn't the context here be e.g. "the Moon": https://github.com/Stellarium/stellarium/blob/0b047c7b06dd73c18d6012079ad60f7cba02539e/plugins/NavStars/src/NavStars.cpp#L599-L600

maybe it might help translators to somehow list the set of known contexts

[axd1967]

I'm building knowledge here: for example, to exclude "egyptian month name", use -context:egyptian (the context filtering seems to also work on parts of context strings).

the question is how a translator can find such "context strings"... (I can do a grep "qc_("-r ... )

Not sure yet what the difference is between N_() and qc_(), but maybe latter should be used whenever possible?

[axd1967]

Stellarium seems to become an encyclopedia...

https://github.com/Stellarium/stellarium/commit/63a97e00f692b9ce730cd156ea1a02c055597fb6 saw more names being poured in.

I'm aware this is a mass import.

Please make sure to add Transifex context information - especially when generating files via scripts - so that translations can be done in logical blocks (and translators also need a clear explanation how to identify/filter for such blocks), otherwise translators will drop out due to the sheer amount of work.

A question is if it might have been better to use Latin names: Mare Tranquilitatis etc rather than Sea of Tranquility, because this might trigger unneeded waves of translation efforts. The next question will then be - where to draw the line between Latin and English names?