[mainline] there is a need for a en_US translation

[egallager]

Oh, apparently there's also a PR open against poedit to give it diff functionality, too: https://github.com/vslavik/poedit/pull/687

[GunChleoc]

I just skimmed this conversation - the easiest for change management would be to use a translation platform. I think weblate would fit us best. I have been using Transifex to manage my contributions. Both offer translation memory, diff and glossary functions, and additional goodies like placeholder usage checks.

[octalot]

AFAICS, Weblate would still require translators to manually clear the "fuzzy" flags, although it does have syntax highlighting for them (examples from OsmAnd's en_GB translation).

[Pentarctagon]

Weblate was also brought up on Discord as well. The two options for that would be:

• Self-hosting for free, which would involve dealing with the complexity of installing, updates/upgrades, etc ourselves.
• Using their cloud offering, which would be quite expensive by the looks of it - based on their pricing criteria we'd fall into the Enterprise tier (there are more than 10,000 source strings), which is over $3,000/year.

[Antro]

Hi there!

My 2c contribution: what about using the features already included in the .po file format?

The strings starting with "#." are visualized in the "Notes for translators" in poedit. As example, please consider this extract from it.po, Liberty campaign

Code: Select all

#. [campaign]: id=Liberty
#. "marchlander" is archaic English for an inhabitant of a border region, not to be confused with "marshlander"
#: data/campaigns/Liberty/_main.cfg:25
msgid ""
"As the shadow of civil war deepens across Wesnoth, a band of hardy "
"marchlanders revolts against the governance of the new queen. To win their "
"way to freedom, they must learn to use shadows and deception to rout the "
"trained blades of the Wesnothian army.\n"
"\n"
msgstr ""
"Mentre le ombre della guerra civile calavano su Wesnoth, una banda di "
"coraggiosi uomini di confine si ribella alla tirannia della nuova regina. "
"Per uscire vittoriosi nel loro cammino di libertà, dovranno impara a "
"muoversi nell’ombra e ad usare l’inganno per sconfiggere le agguerrite lame "
"delle truppe di Wesnoth\n"
"\n"

It leads to this in poedit

As you can see, the bottom-right subwindow is quite useful for translator, more than a separate additional .po file, IMHO

As further option, lines starting with "# " are reported in an additional subwindow "Comments", so we could use the "#." for the correct english sentence and the "# " for any comment that could help the translation.
As examples, another extract from Liberty with suggestion for the translator and a "communication" between translators in the comment...

Code: Select all

# XXX Da concordare la traduzione definitiva
#. [unit_type]: id=Fugitive_Peasant
#: data/campaigns/Liberty/units/Villagers.cfg:137
msgid "Borderer"
msgstr "Guardia di confine"

Ciao
A

P.S. The "#:" lines are the "code occurrence", i.e. the source files that use the string

[octalot]

My 2c contribution: what about using the features already included in the .po file format?

Although that's useful for strings like Liberty's, that's a side-issue that was added to the thread by Nemaara and myself.

Demario started this thread for the issue of the number of fuzzy strings caused by trivial changes to the English text, but so far we haven't received much feedback on those from other translators. As you're a translator, please would you add your insights on that?

[octalot]

The following idea is implemented in #6634:

• Do a pot-update, cherry-pick the trivial changes to the .pot files and discard the other changes.
• Apply those cherry-picks to the existing .pot files.
• Merge the new .pot files into the .po files, but filter out the new fuzzy flags when committing to Git.
• Afterwards, run a normal pot-update which will add fuzzy flags for any string changes which weren't included in the "trivial" set.

Results for 1.16.3 are 130 trivial changes being merged without marking strings as fuzzy, 28 changes that do mark strings as fuzzy, and a few completely new strings.

[demario]

But statistics show that not so many team are able to keep up with the changes, basically only the most active ones: Brazilian Portuguese, Italian, Turkish, Russian (with Spanish, Japanese and Chinese to a lesser extend).

Two weeks away from this statement and it is not true anymore.

Stats on April 24

Russian and Brazilian Portuguese (with Spanish) have now 500+ fuzzy strings on 1.16 branch. It shows how senseless this whole thing is. That may be a couple of days of work for the active teams, but for a on-person team, that is a lot of regressions to check.

Can you see a pattern here?

Stats for Delfador Memoirs

That is the proverbial trying to catch a moving target applying to translation in stable branch.

If you can't work out a system where you don't break translations by changing en_US text, at least apply the same rule for translatable strings as you do for code and WML: do not allow changes to be ported to the stable branch if they break compatibility (with existing translations).

I.e., why is there so much churn occurring in the translatable strings? (Why are there 80 changes to a single campaign in a bugfix release of the stable branch?)

That is indeed a good question.

[max_torch]

If you can't work out a system where you don't break translations by changing en_US text, at least apply the same rule for translatable strings as you do for code and WML: do not allow changes to be ported to the stable branch if they break compatibility (with existing translations).

In your opinion, at what point can changes be ported to the stable branch?

[gnombat]

In your opinion, at what point can changes be ported to the stable branch?

What do you mean by "ported"?

Personally - I would argue that most text changes should only be made in the development branch (e.g., 1.17). Then they will automatically end up in the stable version when the next stable branch is created (e.g., 1.18). This is actually the simplest way to do things, because there's no need for any porting step.

There might be some cases where there's a serious bug in the stable version which requires modifying or adding translatable strings to fix. Obviously that is not ideal, and if there is a way to fix the bug without altering the translatable strings then that would be preferable, but there may be some cases where changing the text is unavoidable. For a bug like that, it will be necessary to port the bugfix (for example, the fix could be made first in 1.17 and then backported to 1.16, or the fix could be made first in 1.16 and then forward-ported to 1.17). But that will (hopefully) be rare and is unlikely to require changing more than one or two translatable strings (so it is likely to be manageable by translators).

[Michal-]

Hello, here is one from two-member Czech translation team.

I work on the translation for 3 years (since 1.14.7) and today we have 100 % in stable and 6 messages to translate in master.

I accepted two facts - en_US is the main language and the game is not finished yet (a change is not a bug, but a feature, because the game is still improving).

From my point of view I see no gain in the original proposal and I disagree with it.

I can fully agree/identify with Celtic Minstrel.

All fuzzy messages are useful for me and I disagree with reducing them by some tools or a workflow. Sometimes they show that we translated the bug, sometimes we notice another bug in our translation thanks to revising the fuzzy. Change in color of language is the change which I want to know about.

I have the use of many tools which help me with the translation, so I have no such requests on developers, which are mentioned in this thread. It would be my pleasure to share my experience, if someone will be interested.

If I could propose something, then it would be the very opposite - to simplify development and workflow. Simply to abandon two branches development and focus on one master with every version released as stable. If something bad happen, there is always older version, which I can use until the bug is fixed. This even includes incomplete translations. If it works for Linux kernel and many other today's projects, it can be useful for Wesnoth too.

[Pentarctagon]

I have the use of many tools which help me with the translation, so I have no such requests on developers, which are mentioned in this thread. It would be my pleasure to share my experience, if someone will be interested.

I think that'd be very helpful.

If I could propose something, then it would be the very opposite - to simplify development and workflow. Simply to abandon two branches development and focus on one master with every version released as stable. If something bad happen, there is always older version, which I can use until the bug is fixed. This even includes incomplete translations. If it works for Linux kernel and many other today's projects, it can be useful for Wesnoth too.

This would be difficult, since Wesnoth still has frequent changes done that break compatibility between the current stable and development versions. We'd lose a lot of players and UMC authors if any particular release could potentially be breaking things. If we need to apply that sort of more strict attitude towards string changes made to the current stable branch though, that would be an option.

It's also worth nothing that the Linux kernel doesn't really follow that development model either: certain kernels are LTS (Long Term Support) kernels which receive bug fixes for some years after release, while features and compatibility breaking changes continue on the master branch. So to my understanding, Wesnoth actually does currently follow a very similar release model to the Linux kernel.

[Michal-]

I think that'd be very helpful.

vim with po.vim ftplugin for editing, git log -S to find out who, when and why, GitHub four-color line/word diff to see what exactly changed, DeepL to verify my translations or find the correct phrasing (try to insert Drogan's By all rights... - there are differences both in Czech and French), perfect Czech/English vocabulary, Czech language institute's precise pages for Czech grammar, Google search with quotes to dive into old English or to measure obscurity of my translation, our GitHub repo to collaborate using Issues, PRs and mainly Suggestions (for authorized corrections), msgmerge to push changes from wesnoth to our repo (yes, with --previous), msgcat to rewrap after vim or GH editing, msgfmt to check changes in the game, msgattrib to remove obsolete messages, vimdiff to quickly sync changes between branches, msync.sh, which uses three msg* utils to sync already translated messages between branches (in case of long-delayed POT update in one branch) and last but not least my bash script w.sh, which glues together mentioned utilities with our repo to quickly manage translations including packing for Nils and making stats (it's tighly tied with our repo, so nothing to share without prior rewriting)

It's also worth nothing that the Linux kernel doesn't really follow that development model either: certain kernels are LTS (Long Term Support) kernels which receive bug fixes for some years after release, while features and compatibility breaking changes continue on the master branch. So to my understanding, Wesnoth actually does currently follow a very similar release model to the Linux kernel.

I don't want to teach an old eagle to fly (you are the developer), but I have a fixed idea, that Linus was pretty strict in the past about API changes, so we can run old programs on new kernels (the principle is do not break things). For me, the LTS kernels are option to live with old known bugs and do not be hit by new ones (in production), but not for compatibility reason. I write this to explain my reasons for the proposal, not to push anybody to do something for my liking.

[demario]

Hello, here is one from two-member Czech translation team.
[...] and today we have 100 % in stable and 6 messages to translate in master.

First let me celebrate with you the success of the Czech translation team. A success story is always nice to hear.

... po.vim ftplugin ... git log -S ... DeepL ... our GitHub repo ... msgmerge ... msgcat ... msgfmt ... msgattrib ... vimdiff ... msync.sh ... my bash script w.sh ...

This impressive list of tools you have collected makes me think: of course software development savvy people make efficient translators. However most of them believe translation is beneath their skill level. It leaves the translation work to less techie people who still want to help.

Believing that the process you apply is available to all translation teams (in terms of needed skills) would be simplistic.
Believing that given you reach that level of performance, it should be the standard for translation for wesnoth would be arrogant.
To put it simply: your team experience might not be representative of general experience at translating wesnoth (unfortunately).

Personally - I would argue that most text changes should only be made in the development branch (e.g., 1.17). Then they will automatically end up in the stable version when the next stable branch is created (e.g., 1.18). This is actually the simplest way to do things, because there's no need for any porting step.

While I agree this is the best fallback solution, this is not the best solution.
First and mainly, it fixes the problem for players, with the update done in minor revision of the stable branch not leading to regression on translations. That would help people who think: what is wrong is this game, the language is back to English after update.

But it doesn't solve anything for the translators. The same number of strings still need to be checked at the end. So the same total amount of work is needed to update, making it a problem for translations with low level of activity. If some translator doesn't show up and fix the mess before next release cycle starts, the translation is broken (with most the work being preventable with a en_US translation: grammar, capitalization, typos...).

I work on the translation for 3 years (since 1.14.7)

The thing with this project is that 3 years is not a big deal, this project runs for 15+ years.
Like, 6 years ago (BFW 1.12.6) French translation had 9 fuzzy and 8 untranslated. Now (1.16.1) the numbers are 864/951. That's the thing: translators have changes in their life (graduation, unemployment, work, spouse, house, child...) who make them drop the project.
The only question that matter: how will the project take care of the work after they left and how it will hold to the responsibility of maintaining the translations it was entrusted with.

You know, we don't remove old portraits until new improved portraits are available. We should not make old translation disappear if no update is available.

[Pentarctagon]

If there are things we as developers can do to reduce the amount of work for translators, then we should investigate doing those things. And if there are additional tools that translators can use to reduce their own work, then they should use them - or ask other translators who are using them how to do so rather than just saying "it's too technical for me".

At some point though, it is simply a fact that Wesnoth remains actively developed and receives sometimes significant updates. There should be no expectation by anyone that the English text for the game will remain static (or mostly static).

Also it's worth pointing out that there aren't any languages that Wesnoth targets for keeping up to date. That is another thing we could perhaps try to do, but again it would require more proactive participation with the rest of the project from the respective translation teams than has been the case at least since I've been around.