What is the use case of separate language for sky cultures?

[10110111]

In the stellarium-skycultures repo the sky culture translations are done all in a single *.po file per locale. But in Stellarium there are two choices of language: one for the GUI, another for the sky culture. And the GUI language is the one that's used for sky culture descriptions, which implies the need for some kind of separation of the strings in the sky culture on import.

What are the actual use cases for this separation into two locales? Is it even used by anyone?

[gzotti]

AFAICR the reason was a wish to operate the program in your native language, but be able to (if you can) read the cultural star names in the original language. There is so much to take into account here.

• As beginner, you want to stay in your language.
• As somebody learning about a culture, you may at one point want to switch over to the original language. In earlier years, the original-language description file was frequently more complete. Now we still have the problem in some SCs.

Much could be mitigated by a thorough redesign of names, occasionally in original glyphs (Chinese, Arab, Korean, Tibetan, ...), transliteration (which may depend on user language!), translation, and configuring a free choice what to display.

Different topic, but related:

What should also be redesigned is the situation around Constellation and Asterism classes. The terminology of the separation used is 20th century post-IAU canonisation. ("Constellation"=one of 88, "Asterism" in-between figures. In other regions/fields, "asterism" is the correct term for the figure.) Worse is its non-derivation, despite similar code which probably can/should be inherited/overridden in some cases. Nothing should prevent asterisms from receiving sky art (raster images). Constellations should accept coordinate lists for "dark constellations" (even fill polygons? Or just encircle/hint at dark edges with coordinate chains), and single-star constellations (e.g. for Arabs) should be allowed, highlighted by e.g. encircling the respective star. There should be options to collect "important" constellations, e.g. Zodiac-12, Zodiac-13 or Lunar Mansions/Lunar Stations. Al of them may be stick figures or sky regions! (Zodiac-12 may highlight the 12 usual constellation patterns, or, as "regions" is just a variant of ecliptical coordinates, not fixed to these same-named constellation figures after all.) Or the 3 "big regions" in the Mesopotamian SCs. This is culture dependent, so any such pattern should be open, also what to do with them: Show optional GUI elements (per culture), show those groups in special colors? These are all possibilities and want-to-have ideas, without having a strict specification yet.

[alex-w]

Important note: translations of description and planets/stars/DSO are different resources for sky cultures - the description one is connected to the GUI option for language. I think in the updated SC we should remove selection of the language for SC from the GUI as global selector for languages - just use "Native/English/Translated" from SC tab to visualize the labels in the sky and use "master" language for descriptions of SC in the GUI.

[gzotti]

Yes, if all descriptions are now translated in full glory via Transifex, the global separate SC language could go away, and a SC screen label language selector/compositor could be configured in the SC GUI. Maybe store label configuration by-culture: I won't use original Korean glyphs (sorry Koreans, just an example. I just cannot read them!), but might want transliteration and translation. I might want Arab glyphs (which I partly can decipher), transliteration and translation, though. The current coding (short "native" _("translatable (informal transliteration/translation where applicable)") ) has to be changed to allow all of this!

[gzotti]

Maybe the Transifex-translated and auto-created HTML files (*.<lang>.utf8) should include a header comment like "Translated file. Do not edit!", so nobody has that idea again to "fix" anything in the non-English versions.

[10110111]

so nobody has that idea again to "fix" anything in the non-English versions

Given how missynchronized some languages are (say, French translation for Chinese sky culture, which has a completely different section structure), I wonder if all this works as expected.

[alex-w]

so nobody has that idea again to "fix" anything in the non-English versions

Given how missynchronized some languages are (say, French translation for Chinese sky culture, which has a completely different section structure), I wonder if all this works as expected.

No, this is dependent on translation team

[10110111]

No, this is dependent on translation team

I mean, from what I saw in the text-extracting scripts, they take bits and pieces of the text and put them into *.pot files, and after translation reconstruct the texts from the *.po files. But in this case we'd see the translations having exactly the same structure, just with English text instead of the native one. Instead, French text seems to have never been reconstructed by the scripts, just translated once and left alone.

[gzotti]

Yes, same observation. Some texts and languages go through Transifex, others apparently don't not. Maybe the old text files are just kept until some translator wakes up and the files are finally reassembled by translated lines? Should we "force" a reset by deleting the existing? Better not, as some texts were good, and maybe some variants closer to the actual culture (e.g. Spanish files for South American SCs) may be more complete than their English counterparts, just that they would have been donated, once, 10 years ago and the author vanished.

A problem with the sentence-wise translation is usually context, and some translators may think about long texts "I have done that 6 years ago, why again now? Is my work time not valued by the maintainers?". I wonder whether the longer texts (description.*.utf8) should be better translated in the long format by some AI, and then (if necessary) only improved and approved by a human translator.

[10110111]

I wonder whether the longer texts (description.*.utf8) should be better translated in the long format by some AI, and then (if necessary) only improved and approved by a human translator.

Yes, this is exactly the same idea as @xalioth expressed. In stellarium-skycultures all the translations have been done by Google Translate (and are often quite ugly), and the next step suggested was to use ChatGPT instead of Google Translate, with a final editing by a human.

But in this case there still is a concern about the irrelevant translation from e.g. Arabic to Arabic, like in the tables sampled in #3712. In this case a human intervention may be required.

[gzotti]

Hm, this may explain the changes in the German version of Rey I have seen elsewhere, which is no longer my own German text but reads a bit clumsy. Unchecked machine translation may come with its own issues.

[gzotti]

Should authors be allowed to provide "original translations/versions" (like English and Arab versions for Arab SC) that are marked "untouchable" somehow if they are meant to be no real translations? The English then goes as template for further translation. Of course, if sb changes the English without the author, the translations will fall out of sync again.