Stellarium
Indian skyculture - add transliteration option
Is your feature request related to a problem? Please describe. Vedic skyculture currently uses devanAgarI script; which is used by the most populous section of Hindus. However, very sizeable subsets use other scripts natively; and their populations are larger than that of many countries.
Describe the solution you'd like Add a transliteration dropdown to the indian vedic sky culture.
Describe alternatives you've considered Maintaining multiple copies of the skyculture in 20 scripts would be unmanageable.
Additional context Transliteration can be done programatically, example - https://www.aksharamukha.com/converter . Libraries which do this exist in Java/ scala, python, js, rust. Particularly the rust one might be of usable from other languages.
All the names can be translated to all "user languages" available on Transifex. If a language does not exist yet, you can ask for its addition. There are methods to mass-translate complete .po-files, these could be applied automatically here. But sorry, I don't know details. @alex-w ?
Thank you @vvasuki!
In future please use Transifex to fix and improve translations: https://app.transifex.com/stellarium/stellarium/dashboard/
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
All the names can be translated to all "user languages" available on Transifex. If a language does not exist yet, you can ask for its addition. There are methods to mass-translate complete .po-files, these could be applied automatically here. But sorry, I don't know details. @alex-w ?
Please note that transliteration is not the same as translation. I certainly am not asking for the latter.
Stellarium support transliteration for skycultures (constellations, asterisms, etc.) and locations (list of locations) only and this support is limited. We cannot provide varisous scripting systems for one language (or country) in same time.
Partially it can be solving by adding extra languages - see Serbian language as example (cyrillic and latin scripts).
There are methods to mass-translate complete .po-files, these could be applied automatically here. But sorry, I don't know details. @alex-w ?
Scripts for filling *.po files + upload these files in Transifex via WUI.
Please note that transliteration is not the same as translation. I certainly am not asking for the latter.
I assume that the program is set to one language, using one glyph system for GUI and text panels. Whatever has been translated is available in this language, the rest is English. Principally, translation for this is working as before.
The 5-element culturalName offers
- native name (in native glyphs). Fixed.
- pronounce: Latin-script pronunciation aid for english speakers.
- pronounceI18n: Transifex-creatable adaptation (i.e., translation) of pronounce. Only this is presented in the GUI. The reason for this is that most such systems have their own history, and often depend on the language of "first contact", so the large early-modern seafaring nations have all different systems.
- transliteration: A (usually) alternative display to "pronounce". A (scientific) transliteration system not aimed at being a pronunciation aid. My principal example is Wylie for Tibetan. Fixed.
- IPA: International Phonetic Alphabet. We hope the respective language experts can add this to our files. Fixed.
- english: The transformation of whatever is provided by the native culture into international knowledge. We recommend it should be a translation (if a name is translatable, like "red shining star"). If it's the untranslatable proper name of a mythological figure, we welcome the myths in the description.md file, to explain what the star/constellation/... means to the members of the culture. This is again translated on Transifex.
The probably easiest way to support the same language with different glyphs is using and Transifexing the "pronounce" string. I expect you don't need another pronunciation aid when reading your own language, so, reading the "pronounce" tag in your own glyphs should do it. But you could also translate the "english" back to your language in your script.
@alex-w @10110111 @sushoff Maybe we should develop and publish guidelines for such cases, so that translations are harmonized?
Well, the separate guideline for translators will be very good advice for translators to harmonize and correcting the translations, because the project has serious changes in localization support.
I suppose it would also be helpful to make auto-generated extracted comments a bit more detailed on what kind of string a name is and how it's expected to be translated. SUG won't be read by 90+% of translations.
- transliteration: A (usually) alternative display to "pronounce". A (scientific) transliteration system not aimed at being a pronunciation aid. My principal example is Wylie for Tibetan. Fixed.
So this would imply having 20+ "translation" files for 20+ scripts; then maintaining and running scripts to keep them in sync? Wouldn't it be better to just mechanically transliterate as needed?
Please note that transliteration is not the same as translation. I certainly am not asking for the latter.
I assume that the program is set to one language, using one glyph system for GUI and text panels. Whatever has been translated is available in this language, the rest is English. Principally, translation for this is working as before.
The 5-element culturalName offers
the list below gives six ...
- native name (in native glyphs). Fixed.
- pronounce: Latin-script pronunciation aid for english speakers.
- pronounceI18n: Transifex-creatable adaptation (i.e., translation) of pronounce. Only this is presented in the GUI. The reason for this is that most such systems have their own history, and often depend on the language of "first contact", so the large early-modern seafaring nations have all different systems.
- transliteration: A (usually) alternative display to "pronounce". A (scientific) transliteration system not aimed at being a pronunciation aid. My principal example is Wylie for Tibetan. Fixed.
- IPA: International Phonetic Alphabet. We hope the respective language experts can add this to our files. Fixed.
- english: The transformation of whatever is provided by the native culture into international knowledge. We recommend it should be a translation (if a name is translatable, like "red shining star"). If it's the untranslatable proper name of a mythological figure, we welcome the myths in the description.md file, to explain what the star/constellation/... means to the members of the culture. This is again translated on Transifex.
90% of the users do not read the description (or even know that it exists). Therefore, I would keep it short & technical (e.g. UN region, classification, license, authors, acknowledgement... - like an imprint) and add all the details and mythology in the ASE, this, in turn, being linked with the browser tool. My idea is that the user would be able to select a constellation within the SC and then query the infos about it on demand without reading a longish description of the SC and picking the infos from there
BTW: The new SC-menu which shall be ready for 25.3 will offer a geo.map which displays the location of the culture - another reason why this should be kept short.
PLUS: in the new SC-maker plugin for 25.3, I will provide a form for description.md in order to have all descriptions of the same shape - that will ease lives of both users who want to find information, and contributors who won't sit in front of an empty sheet of paper but just answer some "questions" for the description
The probably easiest way to support the same language with different glyphs is using and Transifexing the "pronounce" string. I expect you don't need another pronunciation aid when reading your own language, so, reading the "pronounce" tag in your own glyphs should do it. But you could also translate the "english" back to your language in your script.
@alex-w @10110111 @sushoff Maybe we should develop and publish guidelines for such cases, so that translations are harmonized?
harmonization seems to make sense
the list below gives six ...
I knew someone would say 6!=5. The pronounceI18n is not stored in the index.json but is retrieved from the translation system, and only one of the two is shown to the user. Likewise, after english, I should have explicitly mentioned the translated name (the english is not shown unless your user language is english), and in addition the modern name.
90% of the users do not read the description (or even know that it exists)....
Presumably even worse. Those for whom the other figures are just decoration worth an occasional 2-minute look. "Ah, nice, but I'm doing real things here, back to my camera." These also won't ever deviate from some flavour of modern. Those on the other hand who want to read about the other figures and mythology IN the program want to read it in the menu panel (maybe, after all these new options, a new extra tab just for the text? When the geo panel is here, maybe we should split between settings and text view in 25.3). When I am travelling, there may not be Wifi everywhere. Likewise a teacher in areas where Internet access is not guaranteed. The skycultures that come with Stellarium should therefore have a self-sufficient description. The ASE can contain more, and ASE can occasionally (every few months? Every release?) provide an updated version, but we just cannot rely on or guarantee its availability for all users, everywhere, at all times.
My idea is that the user would be able to select a constellation within the SC
You can do that with master now. F3/search, select constellation name. Then call ASE in OnlineQuery. (Configure URL as described in the Guide). This calls for info about whatever the name of the currently selected star/planet/DSO/constellation/Asterism is. If you need specialized button logic, please describe.
- transliteration: A (usually) alternative display to "pronounce". A (scientific) transliteration system not aimed at being a pronunciation aid. My principal example is Wylie for Tibetan. Fixed.
So this would imply having 20+ "translation" files for 20+ scripts; then maintaining and running scripts to keep them in sync? Wouldn't it be better to just mechanically transliterate as needed?
Yes, these are 20+ different "User Language" settings, and translators can be fast or slow, take hours or years to finish. Presumably some parts can be mechanized by some complete-file .po processing done monthly/on demand by one dedicated responsible translator (chief of Indian Transifex group who oversees the 20+ Indian user languages? Or individual Transifex language chiefs?). IMHO adding some additional extra handling in the program just for one language group, which replaces existing working functionality, is a recipe for problems.
I suppose it would also be helpful to make auto-generated extracted comments a bit more detailed on what kind of string a name is and how it's expected to be translated. SUG won't be read by 90+% of translations.
Yes, what comments, how to write context in the json, this should be provided somewhere, and pointed from everywhere else where it matters. Be it SUG (the centralized point of information that comes with the program; IMO best place to specify how to write the json, and what comments and context to give), github wiki (which required online access; maybe an article from developers for developers, how the admittedly complex translation system works behind the curtains), Transifex customized project-specific help (only visible for translators, explaining to watch out for comments. Does such a thing exist?), instructions for direct .po file processing (or just a pointer to applicable external info), ...
what comments
Extracted comments is a very specific type of comments: the ones that start with #. in the .po/.pot files. They are shown in the Transifex UI in the field above the English string.
this should be provided somewhere
Auto-generated means exactly that: created according to the string type itself, by the extraction script. We have a bunch of name types that need special ways to translate each of them.
We have a bunch of name types that need special ways ...
Yes, and probably @alex-w and you are the only ones who have the full overview. For example, now we have (moved from the old system) the translators_comments in the cultural names for planets. Do we still need these tags (does omission have consequences? Could we give a "global" instruction to the json e.g. in the Chinese SCs like "provide Pinyin transliteration in the pronounce tags", which would make the hundreds of current single translators_comments obsolete), or can this be auto-generated in context of NAME tags? Therefore: SC authors need clear instructions what to write in json (from the start, not during our review; reviewers must also know what to expect where), the few .po complete-file processors need to know something else, and our valued single-string workers on Transifex need yet different things maybe in different places.
20+ Indian user languages?
I keep emphasizing I'm talking about scripts, not languages :-(
IMHO adding some additional extra handling in the program just for one language group,
* script group actually. And one that covers billion plus people.
which replaces existing working functionality, is a recipe for problems.
Doesn't replace translation - transliteration is a different, vastly simpler task.
It's a general conceptual thing which must be considered - 1 language can have multiple scripts. For that matter, a Russian may want to read sanskrit or Balinese in cyrillic, rather than latin letters.
I keep emphasizing I'm talking about scripts, not languages :-(
In terms of program settings, these are IMO the same as soon as the strings use different Unicode characters. If not, it's a font question.
It's a general conceptual thing which must be considered - 1 language can have multiple scripts. For that matter, a Russian may want to read sanskrit or Balinese in cyrillic, rather than latin letters.
Yes, this very same process applies to show the pronounce string (in its translated-to-Russian version) to read Sanskrit or Balinese names in Cyrillic.
See Serbian language at Transifex - it has 2 locales for different scripting systems. Maybe Transifex has similar options for Hindi.
P.S. I can’t open Transifex at the moment
Right. And are these two different translation units in Transifex and QTranslator?
P.S. I can’t open Transifex at the moment Ouch. Politics? Does that affect preparing 25.2? Can we do anything?
Right. And are these two different translation units in Transifex and QTranslator?
Yes, of course.
P.S. I can’t open Transifex at the moment Ouch. Politics?
I don’t know. Maybe it’s temporary effect.
Does that affect preparing 25.2?
No.
P.S. It’s temporary troubles in my ISP
Wait! Hindi and Sanskrit are added already. What’s needed else?
I just looked at po/stellarium-skycultures/zh_TW.po and po/stellarium-skycultures/zh_CN.po. Based on that I can imagine having sa_dev (devanagari script), sa_kn (kannada script), sa_te (telugu script) etc..
If you could just create a sa_dev.po from the strings currently provided in the vedic indian skyculture (and nothing else), we should be set for mechanical transliteration. Perhaps you have a script to make such a po file from a skyculture json?
Telugu and Sanskrit languages are in Stellarium/Transifex already.
Kannada was removed due very small translation progress.
Telugu and Sanskrit languages are in Stellarium/Transifex already.
Kannada was removed due very small translation progress.
I don't want these languages (or I'd expect te.po and kn.po, not sa_te.po and sa_kn.po);
and I don't know how to get a sa_dev.po file with just the strings I mentioned from transifex.
and I don't know how to get a sa_dev.po file with just the strings I mentioned from transifex.
I think you can just rename sa.po and alter the header's Language tag. Not sure how well this new name will work with the locale system though.
In any case, for this the Transifex language code needs to be updated too. And then all the other scripts (if they are easy to generate automatically) can be set to be updated (e.g. by the maintainer before a release) with some script that someone has to write.
@vvasuki in any way you should request adding new locales at Transifex on first step, on second step we can add these locales into Stellarium. Or, please, provide script to generate other locales from Sanskrit language.
This is a good task for the community to participate in the contribution into Stellarium. Who wants to help us?
@vvasuki in any way you should request adding new locales at Transifex on first step, on second step we can add these locales into Stellarium. Or, please, provide script to generate other locales from Sanskrit language.
Or, to start off, I could generate a bunch of po files by running the script on my computer and send a pull request. But first I need this-
If you could just create a sa_dev.po from the strings currently provided in skycultures/indian/index.json (and nothing else), we should be set for mechanical transliteration. Perhaps you have a script to make such a po file from a skyculture json?
The two sa.po files I see seem unrelated.
The two sa.po files I see seem unrelated
Indeed, as the path to them says, one is for SC descriptions (from description.md), the other is for everything else (from index.json).