-
-
Notifications
You must be signed in to change notification settings - Fork 792
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is the use case of separate language for sky cultures? #3741
Comments
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.
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. |
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. |
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 ( |
Maybe the Transifex-translated and auto-created HTML files ( |
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 |
I mean, from what I saw in the text-extracting scripts, they take bits and pieces of the text and put them into |
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. |
Yes, this is exactly the same idea as @xalioth expressed. In 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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: