[Mod] Advanced Trains [advtrains] [2.4.3]

[yw05]

The Advtrains wiki has enough problems and l10n (really internationalisation but i'm sick and tired of English) will only make things worse.

A key sign an approach isn't working. When you build a railway next to the sea, the railway might be washed out. Building a third rail for electrification would just electrocute all the fishes, so we can't do that (no to maintenance hell). The best approach is to take it some way inland. Sure, the old railway was built on a narrower gauge to handle space constraints, but we should upgrade the gauge to be better, such as Standard gauge for compatibility for a lot of other rolling stock. We'll just widen the axles of current rolling stock.

In terms of railway construction, there are enough methods to prevent (or, at least, minimize the effects of) these issues, from building seawalls to using overhead electrification.

Also, we are talking about a wiki maintained by a small group of people, not a railway line maintained by a large company. There are sufficient practical differences that do not make the maintenance of both things comparable.

We could do the same witth the wiki. Currently, issues like internationalisation (there, i said it) could be solved by using a different approach instead of adding onto what we already have. The gauge problem is quite heavy but can be solved through a automatic tool or human power, so the syntax can be converted (i used a tool to change to Tiddlywiki after my Dokuwiki broke down, so i used an automatic converter and very little was left to perfect.

I'm not saying we should do this, just forcibly shoving images into your head to help visualise the problem of internationalisation (there, i said it AGAIN). I worry that if we don't provide a solution, people will make their own solutions in protest because there's this really cool mod they want to show their English-free Italian friends but they need to know how to do it. And that will lead to an even deeper circle of maintenance hell. In fact, i asked because i'm planning to make newsletter translations in the future, basically confined internationalisation.

Regardless of the somewhat disputed usage of the term "internationalization", what I described are actual problems. What is, then, your proposal to solve the issues I mentioned earlier besides an empty "there are different methods"?

[56independent_actual]

💥🚄

[yw05]

what I described are actual problems. What is, then, your proposal to solve the issues I mentioned earlier besides an empty "there are different methods"?

Simple: a comparison system. A small program can check if commits on two wikis are within a day (time configurable) of each other, and if not, flag them up so a translator can open both sources side by side, working on the older commit to bring it up to date. A little flag on the editor could also be used, a bit like "this is a minor edit" but instead "this edit does affect other languages", so the program can flag up edits based on this flag.

The program comes in the form of a plugin and might even exist on other wiki software.

... as if that would solve the problem, and yes, Dokuwiki has a translation plugin that helps with translations and (according to the description) gives out warnings on possibly outdated translations.

What does it mean when the original version of the page has changed? It can mean anything from "a typo was corrected" to "this entire page is rewritten with different information". You can, of course, check what changed, but how much would the diff help a user who does not know English if there are significant changes? People who do know English will likely switch to the English version and move on, especially if they only want to look up something on a particular topic, and the rest of what they look up, such as when clicking on links, will mostly likely be in English - and, eventually, they will switch to the English version of the wiki altogether.

The mechanism of comparing the last modified time also does not solve the problem of people temporarily saving their translation work on the wiki (or only translating the part of a page that they can figure out how to), and people do forget checkboxes like "this is a minor edit". You will still end up with outdated information even if it is not flagged as such.

There is also the (uncommon) situation where a "translated" page includes more information than the English version (because, for example, the topic of the article is somehow "closer" to the language). Comparing the time of the last modification will not help with this at all.

Essentially, the difference in the quality between the English and the translated version of the wiki will likely result in people preferring the English version unless for certain topics, and people who do not know English are likely left behind despite localization work.

[56independent_actual]

💥🚄

[yw05]

how much would the diff help a user who does not know English if there are significant changes?

Automatic machine translations of the English page alongside the original. It will be sloppy but it will be very helpful.

Machine translation is a known disaster. There are enough jokes about machine translation messing up terribly, and there are not funny when it comes to serious topics (more importantly, many of those jokes, at least the ones i have heard, are real).

The mechanism of comparing the last modified time also does not solve the problem of people temporarily saving their translation work on the wiki (or only translating the part of a page that they can figure out how to), and people do forget checkboxes like "this is a minor edit". You will still end up with outdated information even if it is not flagged as such.

Maybe we can use an average size comparison. If the size now drastically diverges from the average size of pages about a week into the past, we can use that as more evidence of big changes (such as documentation for an overhaul of say, the train crash system (which might document the physics involved in now dramatically throwing trains off the track and damaging blocks based on speed, 5 megabytes of text added)).

I am not too sure about size comparison, especially that I do not have any data on this topic (I could work on generating some from existing translations in the source repo, though)

Essentially, the difference in the quality between the English and the translated version of the wiki will likely result in people preferring the English version unless for certain topics, and people who do not know English are likely left behind despite localization work.

How does Wikipedia manage its many languages?

I do not know much, but my understanding is that it does not manage languages as a model of templates and translations, so there is theoretically no problem with pages being out of sync with their English counterparts. However, this is not surprising for Wikipedia, considering that certain pages are more "interesting" to users of a particular language (e.g. cities, roads).

Different versions (in terms of language) of Wikipedia are also managed separately, so people contribute to various pages without being required to use other languages as a template (although it is, in some cases, a good idea to translate from a different language).

Wikipedia also differs from the Advtrains wiki though. Wikipedia pages in other languages may have less information, but the information is generally accurate, and rewrites or drastic changes are rare. Advtrains is not fully mature, and it is not uncommon to rework certain features, leading to notable changes to the corresponding wiki page.

[56independent_actual]

💥🚄

[56independent_actual]

💥🚄

[yw05]

Machine translation is a known disaster. There are enough jokes about machine translation messing up terribly, and there are not funny when it comes to serious topics (more importantly, many of those jokes, at least the ones i have heard, are real).

As i said, it would be sloppy. However, i have seen one rouge wikipedia template basically saying "expand this page, you can use machine translation, but clean up". This could be used here. When editing a page, there is a translated version, and you can copy bits over but only after you verify you have cleaned it up.

English Wikipedia does not seem to like machine translations, and you will likely end up "cleaning up" a lot of things after using machine translation to the point where translating by hand is faster.

I am not too sure about size comparison, especially that I do not have any data on this topic (I could work on generating some from existing translations in the source repo, though)

It would be quite intresting. I have an idea for a Wikipedia bot which sees if other language pages have a star, and then on all other language wikis, says "please add info", using the template i mentioned above.

Relevance?

I do not know much, but my understanding is that it does not manage languages as a model of templates and translations, so there is theoretically no problem with pages being out of sync with their English counterparts. However, this is not surprising for Wikipedia, considering that certain pages are more "interesting" to users of a particular language (e.g. cities, roads).

Yes, that's the system i would like to work to.

The roads thing is very true. I was looking at information about the Bilbao-Zaragoza AP-68, and i went to English wikipedia. Most of the road pages say things like "This motorway has been delayed and is expected to open in 1946" and then i have to remove that and say "I have literally been on this road, and yes, definately looks open, a bit old, but open".

Get to the point. Wikipedia did not exist before 1946.

Different versions (in terms of language) of Wikipedia are also managed separately, so people contribute to various pages without being required to use other languages as a template (although it is, in some cases, a good idea to translate from a different language).

Compromise: I download Advtrains wiki and host a Spanish translation on my dormant server. I manage the Spanish community, y'all manage the anglosphere.

To complement what I wrote earlier: different versions of Wikipedia are relatively separate from each other in terms of content, but they are all hosted by WMF. I am not sure why you want to host a separate copy of the wiki only for translations.

Wikipedia also differs from the Advtrains wiki though. Wikipedia pages in other languages may have less information, but the information is generally accurate, and rewrites or drastic changes are rare. Advtrains is not fully mature, and it is not uncommon to rework certain features, leading to notable changes to the corresponding wiki page.

So basically Wikipedia is a 6-lane motorway built atop a mountain and Advtrains is a narrow-gauge railway line built next to the sea which connects to an active volcano.

Explain.

I think Advtrains would do well with a "translation team", working to translate various faucets of Advtrains to other languages and focused on furthering Advtrains's outreach. For example, an Italian-speaking member of the team may work on creating Italian translations of the UI and wiki whilst also advertising Advtrains's benefits across the Italian-speaking Minetest community.

As soon as this idea gains shape, i might write a special feature on how to join in the Advtrains Newsletter (which might even have a new Bolétin de Ferrocarils de Minetest to complement the special feature)¸ as well as what to do. Maybe a seperate newsletter for the team can be made if it gains enough traction, discussing what has happened in the space with article titles such as "Italian translation completed" or "After endless "¡Mañana!", Works begin on Catalan translation" or even "German Government integrates Advtrains as one of the accepted Engineering Project types".

Have you actually looked into the history of the l10n branch?

Currently two people have ever contributed to the l10n branch since it diverged from the master branch. Calling two people a team will not improve anything.

Stop daydreaming.

But then that brings on the topic of lingua franca for the whole team. Here are some solutions:

• Use English, continuing it's expanding dominance across the world
• Use Esperanto, making sure everyone is equally disadvantaged and has to learn a language(actually no as speakers of the language its based on will understand more without learning, same reason Italian wikipedia is just a bit harder then Spanish wikipdia to read for me)
• Get team members to translate to monolingual members of the team (Sophie suggests an idea in Italian, Mary translates it to the only other langauge they know, English, and the rest of the English speakers translate it to their own languages)

I think that there should also be a small noticeboard for people to upload things that have happened, like "Signals-ks recieves a massive rework and i wouldl ike to see wiki translations" or "Work begins on Zulu advtrains, please help"

I am not sure why you are bringing this up for discussion and how this is relevant to l10n work.

[56independent_actual]

💥🚄

[yw05]

A fluent Italian speaer may not want to get head-deep into translating the UI, making a new fork, navigating the weird git website, get all confused and give up, especially on a tiny branch.

I have told people in various occasions (private discussions, in the Advtrains conferences, etc) that they don't need to worry about the technical aspects because they only need to go as far as sending the translations (and that they can send the translation files directly instead of as patches). Yet so far I have only got translations from one person (in French, by the way), besides doing some of the work myself. So f*ck those who don't even know how to send emails.

But with the team's multilingual support pages, this can give more confidence to the budding translator.

I am not sure why people should do translation work if they don't understand English. We also expect translations to be of (somewhat) good quality, so pure corrections should be rare, and other improvements likely require some knowledge of the context.

There is a 10n README, by the way, and language-specific translation notes are written in the target language (with the exception of Chinese, to avoid writing more or less the same thing twice)

• Documentation translation and upkeep

I am quite skeptical toward how far we can get with documentation translation if there is not even sufficient work on UI translations (which requires much less effort).

There is also some uncertainly regarding how documentation should be maintained, so I would not get into translation at the moment.

• Support for learners of translation

I expect translators to at least be able to write in the target language somewhat naturally. People who are not even able to do this should not do l10n work.

• Penetration of advtrains across the Minetest community

I would like to see Minetest in general being used more widely. Advtrains is already somewhat known, from my experience, and IMO it is the improvement in quality that will bring more users.

I am not sure why you are bringing this up for discussion and how this is relevant to l10n work.

Because you can't organise people without a common language. The livery team uses English, but what will the Translation Team use? Esperanto? English? A disparate array of languages?

I am not sure why a hypothetical translation team would be expected to (generally) use a different language in English, and I am still not sure why you need to bring this up specifically for localization. (Of course, within a group focusing on a specific language, it is obviously understandable to use that language.)

By the way, I can make a short presentation on the translation work so far, if that is requested.

[56independent_actual]

💥🚄

[yw05]

I have told people in various occasions (private discussions [...])

The Translation Team should have a knowledge hub where you can find information without bothering developers. Would Wikipedia be the thriving place it is when you can't visit the great documentation and instead have to ask admins on how to do things ("Excuse me, what was that machine translation template again? I saw it before and forgot it" "Go away, you're not even a registered user so i won't waste my time on you")?

We have enough places to put information. Considering that there is little interest in keeping information up-to-date in multiple places, we do not need yet another place for this purpose.

I am not sure why people should do translation work if they don't understand English. We also expect translations to be of (somewhat) good quality, so pure corrections should be rare, and other improvements likely require some knowledge of the context.

Imagine this: One person can speak English and Italian. Another person can speak Sicilian and Italian, but not English. The translation could be handed from English to Italian, and than from there to Sicilian.

I would discourage that though, as it can cause confusion if someone translates a piece of text from English and someone else from another language (this is particularly the case if the translation used for reference is suboptimal and not pointed out).

Also, MT itself does not have support for dialects, as far as I am aware of. The closest thing to this that we have at the moment is with Chinese (which has two variants), but both translation files are updated.

I expect translators to at least be able to write in the target language somewhat naturally. People who are not even able to do this should not do l10n work.

I mean help on how to do translation, such as which software can be used to translate, best practices, and other things. Maybe multilingual people don't know how to translate things into other languages.

This could even extend so far as to tell people to try to avoid things which may cause confusion (oil extract can be describes as a "mystical white liquid", which can be a euphemism for unrelated things).

Translation practices and translations for certain terms tend to be standardized for a specific project. This is part of the reason I wrote that README file.

[56independent_actual]

💥🚄

[56independent_actual]

                                                                   

[yw05]

• General translation tips (contains help on translation in general - maybe the page is so general unrelated websites will link to it, increasing advtrains penetration lol)

That is already covered by the l10n README, and I am currently unwilling to update the wiki, as seen in my past activity.

• Proposals (namespace containing proposals related to translations, like a wiki plugin or GUI translator,)
  [/list

There is a GUI for editing translation files, and I showed this off as early as March 2022.

or Spanish and English and Vietnamese signals

That is beyond the work of localization.

• Localising UI (info on working with l10n branch)

That can be easily replaced with

• git log
• git blame
• Reading the mailing list
• Some more code in the l10n GUI

Speaking of the mailing list, @gpcf: What is your opinion on a advtrains-l10n mailing list?

• Translation Team (info on the group and what it does)

Yet I still do not know why we need it and how it will make things differ from the current situation.

• Advertising Minetest and Advtrains (info on promoting the benifits)

That is not up to the translation team to do.

• Notices (latest first chronological order of various events specific to localisation)

IMO notices should be sent via email instead.

• Wanted languages (contains languages which would do well with a translation with reasons (Arabic because a lot of people speak it, Hindu because it's the third highest adding L1 and L2 speakers, and others for example))

Do we have any statistics on the languages that the current users of Advtrains speak?

Arabic and Hindi both have rendering problems in MT, as far as I know.

Regardless of that, a list of "wanted languages" is unlikely to be useful considering that only those interested in working on l10n will help (and they may not know/want to learn the target language only because we need translations to it)

Can't dialects be represented by underscore ISO codes, like en_us and en_gb?

Minetest seems to have a hard-coded list of supported locales, and OSes appear to sometimes have (theoretical) support for other languages.

The ISO 639 codes only defines language codes (without the country and encoding) such as "en", "de", "fr", so I am not sure what you mean exactly by "representing dialects by underscore ISO codes".

Interestingly though, I played around with locale overrides (env LC_ALL=...) and got mixed results. Specifically, de_CH makes Minetest run in the German locale, but zh_HK resulted in the English locale.

Also, my system seems to support the yue_HK locale, but Minetest (or Irrlicht) clearly does not like it:

Code: Select all

2022-11-01 21:22:12: WARNING[Main]: Irrlicht: Locale not supported. Falling back to non-i18n input.

[56independent_actual]

💥🚄

[yw05]

That can be easily replaced with

• git log
• git blame
• Reading the mailing list
• Some more code in the l10n GUI

Make the page link to these areas for easier access (what's better for those walking to the shop: a disparate collection of unsigned paths or a shiny signpost pointing down the shortest path with ramps instead of stairs for people cycling?)..

Most information is on the l10n README. What I mentioned above is not specific to l10n, so no.

IMO notices should be sent via email instead.

I mean notices like "Success! German government succesfully implements Minetest into one of the computer science projects due to translation work" or "Italian version complete!".

L10n-related discussions and notices belong to the mailing list just like other information. Notable events can obviously be put on the wiki as well.

Do we have any statistics on the languages that the current users of Advtrains speak?

I remember seeing some info on Minetest downloads by country. Germany was in really dark blue and the UK in lighter blue and Saudi Arabia in even lighter blue. It was intresting and can draw vauge links to what languages Minetest users speak. You'll probably have to look at the server logs to track down which IP addresses downloaded the package and see where they come from.

I would be more interested in getting results by directly asking users.

[56independent_actual]

                                                         

[56independent_actual]

💥🚄

[Blockhead]

What language should i use for commit messages?

Here is what I think:

For wiki pages, the language of the page you're editing. I also think a disclaimer should go on top of translated pages to let people know this page is a translation of the original and authoritative English version, as well as the disclaimer that orwell added in earlier articles that stated the version of advtrains that a wiki page was written for which we should probably be adding to a lot of newer pages. Please don't try to debate me on the primacy of the English version with arguments like 'English supremacy'. The wiki's main language will always be English because advtrains documentation has always been in English and it is better to guarantee 100% documentation coverage in the one language we already have than let people go and write wiki articles in various languages that are not available in English. If the documentation and wiki were primarily in German, the mod author's native language, I would argue that the German version should continue as the primary version.

For advtrains localisation work that goes in the main git repository:

• For contributions that add a number of translations, make the first line of the commit message the usual short description in English, then write a fuller description in both languages in the commit. For instance, if you translated the interlocking part then your subject line would be like es l10n: Interlocking and the message body may contain brief notes about things like tu-vos (for instance German uses Sie-form), untranslated terms, genders and so on that you had to make a decision about for the localisation work.
• For typo fixes it suffices to write the old->new words and omit any further description; it's not useful to translate such corrections into English.
• For some grammar fixes still leave a longer message about grammar such as if you had to fix a lot of strings that had some common grammatical error. In some cases it may not be necessary e.g. if correcting the gender of a word in German then a commit line like: Zug: Nominativ -> Genitive may suffice.

[yw05]

In addition to what Blockhead wrote, I don't think there should be much difference between writing commit messages for the l10n branch and on the wiki.

I would give some details on how I wrote commit messages:

• Commit messages in English are always accepted, provided that they are appropriate. This is useful for commits involving multiple languages or multiple variants.
• Commit messages in other languages should, in some way, indicate which language is used. This is optional on the wiki, as the modified page name can be used to infer the language.
• Commit messages should also follow the formal requirements in the translation notes. Currently, this is only relevant to Chinese, as there are some requirements on the use of fullwidth and halfwidth punctuation marks.

I do not have other expectations otherwise, provided that a certain level of quality (in particular, accuracy) is met.

[56independent_actual]

💥🚄

[yw05]

Commit messages in English are always accepted, provided that they are appropriate. This is useful for commits involving multiple languages or multiple variants.

Appropiate as within context of the page edit or just not being taboo?

Appropriate in terms of informative (of the changes) with proper language.

Commit messages in other languages should, in some way, indicate which language is used. This is optional on the wiki, as the modified page name can be used to infer the language.

Does the writing system suffice (when using "añadir", the ñ is generally related to Spanish as Portugese would be "ãñãdĩr" or something, it has more tidles) or do i have to make a funny little "es" as in "es: añadir más informaccion"?

I have use language codes so far, and I would suggest doing so as it would be (for me maintaining the l10n branch) easier to read the log.

[56independent_actual]

💥🚄

[yw05]

I have use language codes so far, and I would suggest doing so as it would be (for me maintaining the l10n branch) easier to read the log.

Makes sense. But what if the article itself contains the language code and all commits are in that language? Consider "[es] Boletin de Octubre 2022" for example

I wrote in a previous post that putting the langauge code is not needed for wiki pages. I did this in the l10n branch to (help others) keep track of the translation files modified in each commit without using git show or similar commands. This is obviously not relevant for the wiki, where you can only submit changes for one page at a time.