[mainline] there is a need for a en_US translation

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderator: Forum Moderators

Forum rules
Before posting a new idea, you must read the following:
Post Reply
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

IceSandslash wrote: May 15th, 2023, 4:13 am
3. What, specifically, is meant by en_US here?
At the moment of its creation, for each campaign/domain, it would be a file of the form:

Code: Select all

msgid "Same string in both lines."
msgstr "Same string in both lines."
After that, this file is to contain the canonical version of Wesnoth texts, including minor ortography, punctuation, and grammar fixes, but also potentially uncommon archaisms, and fad English-specific phrases/memes, etc., all according to the relevant campaign author's opinion (SP lead would have veto rights regarding this judgment call here. I suppose that's not new.)

This follows the fact that Wesnoth mainly follows US English, as opposed to British, Australian, or other dialects. (I have seen a few instances of British spelling, though, which will have to be fixed.) Someone might come up with the idea of adding support for other regional variants of English, but that would be a separate proposal.

Major changes regarding intention, personality, or whatever else the campaign author deems important would have to go into the campaign source, and therefore modify the `msgid`, with impact across all languages.

These judgment calls regarding importancy affect the string freezes. Some minor English text fixes may be added, to the .po file only, during string freeze, again according to the judgment of the author. Translators may follow the judgment calls through process 2A, or override them through process 2B.
I'm not sure what you mean when you say that the "canonical version of Wesnoth texts" will be in the en_US file, but then also that "Major changes regarding intention, personality, or whatever else the campaign author deems important would have to go into the campaign source, and therefore modify the `msgid`, with impact across all languages". It sounds like it ends up being that the text in the campaign source is the true text, and en_US is for superficial changes so as to not bother translators.

That then seems like in practice it's an alternative way to do what the pofix tool was previously used for?
IceSandslash wrote: May 15th, 2023, 4:13 am
1. Would this mean anything for the po update I run for each release? Specifically that being scons pot-update update-po4a manual.
--pull-variants may be run either in the Wesnoth-wide build process, or by translators that intend to follow 2B.
If it's done in the build process, it probably should be done only for a few languages which are interested in it. Doing it in the build process would mean that translators don't need to look for the most up-to-date en_US.po file themselves.

On the other hand, translators that are the most interested in quality may want to re-run this all along the string freeze process. It's possible this may introduce the need for two string freezes: one for the source, and another one for both source and en_US.po, but that requires first-hand experience.
2. Is this something that each individual translator/translation team would need to run themselves?
--set-variants-fuzzy and --set-variants-done are to be run by translators that intend to follow 2B.
--prune-variants would always be run either by each translator or by ivanovic. This would remove the #. updated(en_US) comments, but NOT the translator-authored # updated comments.

Translator teams not interested in closely matching the en_US variants don't need to run anything.
My take away from this is that it's something that would be done manually by the translators, unless one or more of them come to me and ask me to do it as part of the release process for some reason.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
IceSandslash
Developer
Posts: 17
Joined: February 12th, 2023, 1:13 pm

Re: [mainline] there is a need for a en_US translation

Post by IceSandslash »

I'm not sure what you mean when you say that the "canonical version of Wesnoth texts" will be in the en_US file, but then also that "Major changes regarding intention, personality, or whatever else the campaign author deems important would have to go into the campaign source, and therefore modify the `msgid`, with impact across all languages". It sounds like it ends up being that the text in the campaign source is the true text, and en_US is for superficial changes so as to not bother translators.
Suppose that you write a manuscript for "History of Wesnoth", and use people's IRL names all through the book. Then you go to a publisher, and you get assigned an editor who makes you add their nicknames, too. You do that, and only the revised version becomes available to the general public. Now, which is the true text? Is that a meaningful question? How does that help into answering which version translators should base their work on? Some people might prefer to closely follow the original publisher, while others may research into the personal author background, as well as their original intentions.

In this proposal, WML/Lua text consistency is meant exactly to alleviate translator workload, while the PO en_US version makes it possible for translators to do their own judgment calls in the editorial vs manuscript debate. The fact that self-editing would be a common practice would grant translators better insights so as to reap further benefits.
That then seems like in practice it's an alternative way to do what the pofix tool was previously used for?
That would be one of its usages. However, the extra syntax empowers translations in the following ways:

1. Tiered translations: By noting what both sources said the last time any given string was translated. For the issue mentioned in the mailing list, what the translator would get as a fuzzy change is:

Code: Select all

#,fuzzy
#| msgid "Old WML/Lua text"
msgid "New WML/Lua text"
msgstr "Semantically correct translation, but may need improvement."
Then, they could mark the string as still useful by losslessly editing it into:

Code: Select all

# updated: "Old WML/Lua text"
msgid "New WML/Lua text"
msgstr "Semantically correct translation, but may need improvement."
Once/if they decide to do process 2B, this string will be flagged as fuzzy again. No information lost along the way.

2. What you see is what you get: All relevant texts are available to the translator all along their work.

3. No unpredictable post-edition: pofix has a few limitations and bugs that are mentioned in its source code (e.g. it cannot handle half-updated files), and some that are not (e.g. it cannot handle multi-line msgid, and it may mangle translator-authored comments).
IceSandslash
Developer
Posts: 17
Joined: February 12th, 2023, 1:13 pm

Re: [mainline] there is a need for a en_US translation

Post by IceSandslash »

To get a sense of the example I provided, the following screenshot is what POEdit would show for a fuzzy string. Note that the previous source text may be copied.

Image

The following screenshot shows the translator adding a note that this string was last updated for the old text. (The string from "previous source text" was pasted, and "updated: " was prepended).

Image

And the next is how it looks after the translator removes the fuzzy flag (aka "Needs work"). (The "previous source text" part is gone after reloading.)

Image

The status in the first screenshot would be restored by running --pull-variants and --set-variants-fuzzy.
User avatar
octalot
General Code Maintainer
Posts: 783
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: [mainline] there is a need for a en_US translation

Post by octalot »

I'm wondering how much of this can be solved by the roadmap, without needing an en_US translation. With the benefit of hindsight, the mass capitalisation and punctuation changes that were too late for the 1.16 release candidates (so 1.15.14 and later) should only have been applied to 1.17.x; putting them into 1.16.1-1.16.3 was a mistake. However, there haven't been many string changes in the year after 1.16.3, and fewer still that cause fuzzies; some of those were bugfixes and definitely change the meaning of the text (the full list is attached), so would end up in 1.16.x's WML instead of en_US. How much of the demand for en_US is based on the changes up to 1.16.3, rather than the changes afterwards?

I believe there's an open question of whether en_US would get merged back into the .cfg files before releasing a new branch - I think it should, but that also means that the fuzzies appear in the development branch eventually, although at a much more convenient time.

Where would the translation teams put PR #7291's dialogue changes in HttT S03? With the en_US discussion at the time closed, it seemed a clear choice to backport it, but now that we're discussing it again I'd like to ask for new opinions.

Code: Select all

-"I fear so, Konrad. It seems that the orcs have come even here. Here to the place where I was born, where I was trained."
-"I did not think the orcs would have come here. This island used to be so beautiful. We must recapture it! To arms!"
+"If the orcs have come here, their forces at Elensefar must be even more numerous than I feared."
+"Konrad, training is important. If we only have inexperienced troops when we reach Elensefar, then our journey is likely to end in sight of the city’s gates."
+"This island is the place where I was born, and where I learned magic; it used to be so beautiful. We must recapture it! To arms!"
The only ones that would definitely go in en_US are these:

Code: Select all

This one's for en_US, it's an apostrophe fix.
-"We have no time to lose! Let's get moving quickly before the rest of their army catches up with us."
+"We have no time to lose! Let’s get moving quickly before the rest of their army catches up with us."

A clear use for en_US here.
-"Dark years passed; human generations grew up in slavery, and came near to forgetting that their ancestors had been free — and might have completely forgotten were it not for a fateful day in 518YW. That day that changed the lives of the people of Dwarven Doors — forever."
+"Dark years passed; human generations grew up in slavery, and came near to forgetting that their ancestors had been free — and might have completely forgotten were it not for a fateful day in 518YW. The day that changed the lives of the people of Dwarven Doors — forever."

This one could be in en_US. Explanation of why this seems backwards: there was a bug that the second encounter could be skipped, so this was changed from "a third" to "another" in 1.16.2. The bug was fixed and the 1.16.2 change was reverted.
-"In Eloh’s name, not you again. Must I fight you another time?"
+"In Eloh’s name, not you again. Must I fight you a third time?"
Based on the thread so far, this typo correction of a proper noun seems to be the only one where some translation teams would want it and some wouldn't. There were corresponding typos fixed in cs, de, en_GB, es, fr, and some change in tr. However, it caused the English string to show up in the 1.16.9 releases of bg, ca, fi, gd, it, ja, pl, pt_BR, ru, zh_CN and zh_TW.

Code: Select all

-"Very well. If you convince him not to raise his sword against us, the Lintair elves shall grant him safe passage."
+"Very well. If you convince him not to raise his sword against us, the Lintanir elves shall grant him safe passage."
Attachments
20230519_how_many_fuzzies_were_added_after_1.16.3.diff
Text file, .diff extension for syntax highlighting
(6.12 KiB) Downloaded 113 times
demario
Posts: 131
Joined: July 3rd, 2019, 1:05 pm

Re: [mainline] there is a need for a en_US translation

Post by demario »

octalot wrote: May 20th, 2023, 4:14 pm With the benefit of hindsight, the mass capitalisation and punctuation changes that were too late for the 1.16 release candidates (so 1.15.14 and later) should only have been applied to 1.17.x; putting them into 1.16.1-1.16.3 was a mistake.
Hi, I must commend you for acknowledging publicly a mistake from the devs. You're very brave to break the omertà that the development team is always right. :mrgreen:
Still you're confused on the reason why this was a mistake and what rules could be drawn out of this experience.

Let me try to help you thinking this through by killing some of the many misconceptions the development team has about translation
CloudiDust wrote: May 3rd, 2022, 1:43 am there are three problems that this thread tried/is trying to find a solution for:

1. Flavored messages might be too hard to translate.
2. Minor message updates create unnecessary work for translators working on the project.
3. Minor message updates invalidate perfectly/mostly working translations when there are no translators to update the translations.
There are 4 cases to consider:
  • translation done by developers or code contributors:
    this is usually a one man effort done by someone already very close to the development team (github account, discord presence). That's the teams the devs will know more about. I guess I can list ru, es, de (I will discard en_GB from having any relevance to the translation problematic). Their needs will be better understood and quickly answered due to their proximity to the development team.
    The productivity may be high as they are people engaged in different ways with the project.
    Still these teams are in a dangerous situation as they rely on one single person. The translation is not reviewed, leading to an average quality.
  • translation done by teams from 1.5 to 2.5 translators
    that is the most reliable teams as they have no single breaking point and the quality is higher as the work is peer-reviewed. Their main concerns are to avoid burnout from team members and loss of hard earned quality translations. So they will tailor their workflow to fit with the abilities of the people on the team and they will take everyone's engagement into account leading to slower output. The general motivation will be higher as they are actively working with other people.
    That's the teams the project should nurture as they are the long term solution to continuous translation for wesnoth. I guess I can list cs, fr, it, zh_CN. I am not clear about ja, pt_BR, tr, zh_TW
  • completed translations without maintainer
    as the translation was once complete, whole populations could be available to wesnoth if these translations were not made obsolete. I have listed these languages before: Hungarian, Slovak, Galician, Vietnamese, Estonian, Indonesian
    The job of the development team was to take care of these translations and avoid making them obsolete (they are now all below 80% coverage, meaning not even listed for selection).
  • incomplete translations with one or no translator
    these teams are in great danger and the duty for the development team is to actively show that it is worth to get involved (and continue current involvement) because the work will be valued and taken care of while they're making their (looong) way toward the goal of a complete translation.
    Any setback (new hundreds of fuzzies, new strings for unused units) can be a killer.
tl;dr: the development team needs to nurture the most reliable teams, actively show that translations are valued and taken care of to keep and attract new translators and avoid making completed translations without maintainer obsolete.
Michal- wrote: April 24th, 2022, 4:43 pm Hello, here is one from two-member Czech translation team.
This thread is making clear that all teams, including well working ones, have limited number of members.

From my experience, a member can produce 50-70 translated strings per month on a long term basis. That means that teams with 2 members can produce 100-150 strings per month at max. Some temporary speed-up is possibly by cherry-picking easy strings or boosting work right before a release. So adding hundreds of fuzzies or adding 100 new strings is actually adding at least one month of work to each translation team (when most of them are already busy trying to catch up). A new campaign with 800 strings amounts to one year of work for one translator (it is tricky to have two persons to work in parallel on the same domain).
Pentarctagon wrote: Wesnoth's long-standing policy is that the dev branch shouldn't be the target of any translation team and translations they made against it they do at their own risk
Saying that you have warned people beforehand, doesn't free you from any responsibility.

At this time some of the most active translations already have 200+ strings on their plate in master branch for core mainline domains only.
If a translation team can only produce 100-150 translated strings per month, they must start working on the master branch to complete translation of a new 800-string campaign for the time of release of the new version. Sticking to your "long-standing policy" makes it impossible for any team to complete full translation at time of release if the new strings are in the high hundreds. Is that your goal for the release of 1.18?
If not, drop the policy and start talking real business.
octalot wrote: I'm wondering how much of this can be solved by the roadmap
In terms of translation, the roadmap is a mess. There will be 3 new campaigns (the Hybrid Dunefolk campaign, LoW rework and NR rewritten and merged with THoT) just before the 3-month string freeze. How do you expect the teams to complete the translation of the multiple hundreds of new strings in 3 months?
Pentarctagon wrote: there have been complaints from some translators about there being too much churn in the string changes made. Our stance was, and is, that Wesnoth is a moving target
That one should be pretty easy for you native speakers: the stable branch should have no update of the strings up for translation. That's in the word stable. Look it up in the dictionary if you're confused.
User avatar
octalot
General Code Maintainer
Posts: 783
Joined: July 17th, 2010, 7:40 pm
Location: Austria

Re: [mainline] there is a need for a en_US translation

Post by octalot »

demario wrote: May 22nd, 2023, 10:53 am the stable branch should have no update of the strings up for translation
Defining "stable" as "no string changes at all" would require leaving these issues unfixed:
  • #7005 DiD: talk about Dela and the paladins even if neither of those sides arrived on the map
  • #7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
  • #7108 Orbs: negative feedback that the new allied orbs were confusing. Could have had less strings, but having some UI for configuration was better than not having it
  • #7075 Units: Dark Horses didn't have separate strings for male and female
  • #6966 WC: Some things that should have been translatable weren't
  • #6116 Lack of error reporting for the debug unit command
  • Including a preference setting in the fix to #1336, which enables keepalive checking for disconnections from the multiplayer server
Which of those would you accept leaving open, in order to have no string changes? Details of the strings involved are attached to my previous message, they're all ones that changed after 1.16.3.
demario wrote: May 22nd, 2023, 10:53 am In terms of translation, the roadmap is a mess. There will be 3 new campaigns (the Hybrid Dunefolk campaign, LoW rework and NR rewritten and merged with THoT) just before the 3-month string freeze. How do you expect the teams to complete the translation of the multiple hundreds of new strings in 3 months?
It's not clear from the Wiki page, but that's "plans as they were in July 2022". The LoW rewrite and Dunefolk campaign are definitely postponed to 1.19, I believe the NR one is too. OTOH, that gives us the same problem when we reach the 1.19 string freeze; but if a whole campaign is left untranslated that's not as bad as an important text in an otherwise-translated campaign being in English.

Lessons learned from 1.16 will hopefully stop people putting such things at the end of the 1.19 roadmap. While we don't expect people to translate master until the string freeze, things should land earlier to playtest and improve the English prose.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

demario wrote: May 22nd, 2023, 10:53 am
Pentarctagon wrote: Wesnoth's long-standing policy is that the dev branch shouldn't be the target of any translation team and translations they made against it they do at their own risk
Saying that you have warned people beforehand, doesn't free you from any responsibility.

At this time some of the most active translations already have 200+ strings on their plate in master branch for core mainline domains only.
If a translation team can only produce 100-150 translated strings per month, they must start working on the master branch to complete translation of a new 800-string campaign for the time of release of the new version. Sticking to your "long-standing policy" makes it impossible for any team to complete full translation at time of release if the new strings are in the high hundreds. Is that your goal for the release of 1.18?
If not, drop the policy and start talking real business.
The dev branch is, and always has been, a moving target for *everybody*. It's not just translations - we give no guarantee of compatibility even between individual point releases for the UMC APIs (WML, WFL, lua, macros), saves/replays, being able to connect to the addons server or online multiplayer server, etc.

While the contents of each point release of the roadmap are not especially accurate anymore, the dates are still correct, so there will currently be a minimum of 4 months of string freeze before 1.18.0 (the 3 beta releases plus RC1, plus any additional RC releases if they're needed). The "a translation team can only produce 100-150 translated strings per month" and "a member can produce 50-70 translated strings per month on a long term basis" statistics are entirely new information to me, so if we need to implement additional rules around string changes such as:
  • Freezing specific areas such as new/overhauled campaigns (such as WoF) early.
  • No major additions of new strings after a certain point even if there's still not a total string freeze.
  • More than 4 months of string freeze before a new stable release.
  • Target certain languages as being 100% complete before a new stable branch is released.
then those are options we can discuss and potentially do. For that last point however, I will absolutely require active engagement from those translation teams - I will not make Wesnoth's release of a new stable branch dependent on translation teams that barely (if ever) communicate with the dev team.
demario wrote: May 22nd, 2023, 10:53 am
CloudiDust wrote: May 3rd, 2022, 1:43 am there are three problems that this thread tried/is trying to find a solution for:

1. Flavored messages might be too hard to translate.
2. Minor message updates create unnecessary work for translators working on the project.
3. Minor message updates invalidate perfectly/mostly working translations when there are no translators to update the translations.
There are 4 cases to consider:
  • translation done by developers or code contributors:
    this is usually a one man effort done by someone already very close to the development team (github account, discord presence). That's the teams the devs will know more about. I guess I can list ru, es, de (I will discard en_GB from having any relevance to the translation problematic). Their needs will be better understood and quickly answered due to their proximity to the development team.
    The productivity may be high as they are people engaged in different ways with the project.
    Still these teams are in a dangerous situation as they rely on one single person. The translation is not reviewed, leading to an average quality.
  • translation done by teams from 1.5 to 2.5 translators
    that is the most reliable teams as they have no single breaking point and the quality is higher as the work is peer-reviewed. Their main concerns are to avoid burnout from team members and loss of hard earned quality translations. So they will tailor their workflow to fit with the abilities of the people on the team and they will take everyone's engagement into account leading to slower output. The general motivation will be higher as they are actively working with other people.
    That's the teams the project should nurture as they are the long term solution to continuous translation for wesnoth. I guess I can list cs, fr, it, zh_CN. I am not clear about ja, pt_BR, tr, zh_TW
  • completed translations without maintainer
    as the translation was once complete, whole populations could be available to wesnoth if these translations were not made obsolete. I have listed these languages before: Hungarian, Slovak, Galician, Vietnamese, Estonian, Indonesian
    The job of the development team was to take care of these translations and avoid making them obsolete (they are now all below 80% coverage, meaning not even listed for selection).
  • incomplete translations with one or no translator
    these teams are in great danger and the duty for the development team is to actively show that it is worth to get involved (and continue current involvement) because the work will be valued and taken care of while they're making their (looong) way toward the goal of a complete translation.
    Any setback (new hundreds of fuzzies, new strings for unused units) can be a killer.
tl;dr: the development team needs to nurture the most reliable teams, actively show that translations are valued and taken care of to keep and attract new translators and avoid making completed translations without maintainer obsolete.
I think this is the main thing I struggle with, and something I feel like I've repeated at least a few times in this thread. It is difficult to nurture the most reliable teams and show them they are valued when many of the individuals/teams are essentially entirely disconnected from the rest of Wesnoth's development. This can't be just about what the Wesnoth dev team needs to do differently - the communication needs to go both ways.

For example, ivanovic is currently the Translations maintainer, but aside from receiving, checking, and committing translation updates he's mostly inactive. If someone else wanted to take over that role and be more active in communicating and coordinating between the various translation teams and the dev team, that would certainly be helpful.
demario wrote: May 22nd, 2023, 10:53 am
Pentarctagon wrote: there have been complaints from some translators about there being too much churn in the string changes made. Our stance was, and is, that Wesnoth is a moving target
That one should be pretty easy for you native speakers: the stable branch should have no update of the strings up for translation. That's in the word stable. Look it up in the dictionary if you're confused.
Stable does not mean 100% set in stone and unchanging for absolutely any reason. If we need to define stricter limits on what string changes can be made to the stable branch then that can be done, but I don't think that allowing absolutely no changes for any reason is reasonable either. octalot's list of fixes that had string changes are a good example of why, I think.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
gnombat
Posts: 682
Joined: June 10th, 2010, 8:49 pm

Re: [mainline] there is a need for a en_US translation

Post by gnombat »

Pentarctagon wrote: May 22nd, 2023, 5:49 pm octalot's list of fixes that had string changes are a good example of why, I think.
To be honest, I don't find that list of fixes to be very persuasive...
octalot wrote: May 22nd, 2023, 4:12 pm
  • #7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
The issue being addressed here has been around literally since the first release of Wesnoth. "The Siege of Elensefar" has been killing noobs mercilessly without warning since the very beginning. Why does it need to be urgently fixed right now? Why can't it wait until 1.18?
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

gnombat wrote: May 22nd, 2023, 6:46 pm
Pentarctagon wrote: May 22nd, 2023, 5:49 pm octalot's list of fixes that had string changes are a good example of why, I think.
To be honest, I don't find that list of fixes to be very persuasive...
octalot wrote: May 22nd, 2023, 4:12 pm
  • #7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
The issue being addressed here has been around literally since the first release of Wesnoth. "The Siege of Elensefar" has been killing noobs mercilessly without warning since the very beginning. Why does it need to be urgently fixed right now? Why can't it wait until 1.18?
I mean, that's kind of the point though. We're not making these changes because we don't care what translators have to deal with, we're making them becase based on what we know it makes sense to put the fix into the stable branch. If there need to be stricter guidelines on that, we're not going to have an epiphany about it one day on our own - better guidelines for string changes to stable need to be implemented and the reasons behind them made known based on discussions with people doing the translations. And I need to understand why, because I need to be able to explain it to other devs when they get frustrated with me telling them they can't do something.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
demario
Posts: 131
Joined: July 3rd, 2019, 1:05 pm

Re: [mainline] there is a need for a en_US translation

Post by demario »

octalot wrote: May 22nd, 2023, 4:12 pm
  • #7005 DiD: talk about Dela and the paladins even if neither of those sides arrived on the map
  • #7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
  • #7108 Orbs: negative feedback that the new allied orbs were confusing. Could have had less strings, but having some UI for configuration was better than not having it
  • #7075 Units: Dark Horses didn't have separate strings for male and female
  • #6966 WC: Some things that should have been translatable weren't
  • #6116 Lack of error reporting for the debug unit command
  • Including a preference setting in the fix to #1336, which enables keepalive checking for disconnections from the multiplayer server
Which of those would you accept leaving open, in order to have no string changes? Details of the strings involved are attached to my previous message, they're all ones that changed after 1.16.3.
I am not sure what you're asking.
Are you looking for examples of possible exception to the rule "stable branch should have no update of the strings up for translation"?
Or proofs that the "stable branch should have no update of the strings up for translation" cannot be adopted as a rule at the first place?
If it is the second question, there is absolutely no issue in this list that justifies rejecting the adoption of that rule.
Pentarctagon wrote: May 22nd, 2023, 9:22 pm And I need to understand why, because I need to be able to explain it to other devs when they get frustrated with me telling them they can't do something.
That's the point of making it a rule of "stable branch should have no update of the strings up for translation", you don't have to explain why developers need to do things that way: it is done so because that's the rule. You just need to find a explanation for the exceptions (change in stable branch) that hopefully will be in limited numbers. I see none in octalot's list.
Pentarctagon wrote: May 22nd, 2023, 5:49 pm The dev branch is, and always has been, a moving target for *everybody*. It's not just translations - we give no guarantee of compatibility even between individual point releases for the UMC APIs (WML, WFL, lua, macros), saves/replays, being able to connect to the addons server or online multiplayer server, etc.

While the contents of each point release of the roadmap are not especially accurate anymore, the dates are still correct, so there will currently be a minimum of 4 months of string freeze before 1.18.0 (the 3 beta releases plus RC1, plus any additional RC releases if they're needed). The "a translation team can only produce 100-150 translated strings per month" and "a member can produce 50-70 translated strings per month on a long term basis" statistics are entirely new information to me, so if we need to implement additional rules around string changes such as:
  • Freezing specific areas such as new/overhauled campaigns (such as WoF) early.
  • No major additions of new strings after a certain point even if there's still not a total string freeze.
  • More than 4 months of string freeze before a new stable release.
  • Target certain languages as being 100% complete before a new stable branch is released.
then those are options we can discuss and potentially do. For that last point however, I will absolutely require active engagement from those translation teams - I will not make Wesnoth's release of a new stable branch dependent on translation teams that barely (if ever) communicate with the dev team.
There is a clear difference between lua and translation, the first is a thing that developers handle between them and their choice impacts no one else. For translatable strings, the developers makes the calls and the translators suffer the consequences.

You want more communication, but when someone painstakingly tells you what they want, you come up with your own alternatives that "can" be discussed, conveniently delaying decision until god knows when. Who ever asked you to "target certain languages as being 100%"? No one. So drop your absolute requirement because no one wants any bit of that. Is there anything other than a PM flexing muscles to remind people who's the boss?

Discussing with translators is by nature discussing with foreign speakers. It takes me ages to write down my best argument in English. Seeing it nitpicked, twisted to be rejected by native speakers playing on bad faith to understand the sentences the wrong way is a cause of great sadness.
Thinking that someone would be volunteering to take a role that would make this his weekly routine is idiotic.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

demario wrote: May 23rd, 2023, 1:08 am There is a clear difference between lua and translation, the first is a thing that developers handle between them and their choice impacts no one else. For translatable strings, the developers makes the calls and the translators suffer the consequences.
Changes to UMC APIs affect UMC - deprecations, removals, and just unnoticed bugs affect more than just the mainline Wesnoth devs.
demario wrote: May 23rd, 2023, 1:08 am You want more communication, but when someone painstakingly tells you what they want, you come up with your own alternatives that "can" be discussed, conveniently delaying decision until god knows when. Who ever asked you to "target certain languages as being 100%"? No one. So drop your absolute requirement because no one wants any bit of that. Is there anything other than a PM flexing muscles to remind people who's the boss?
You yourself said (bolding mine):
At this time some of the most active translations already have 200+ strings on their plate in master branch for core mainline domains only.
If a translation team can only produce 100-150 translated strings per month, they must start working on the master branch to complete translation of a new 800-string campaign for the time of release of the new version. Sticking to your "long-standing policy" makes it impossible for any team to complete full translation at time of release if the new strings are in the high hundreds. Is that your goal for the release of 1.18?
If not, drop the policy and start talking real business.
If a team completes a full translation at time of release, that means they have 100% of the strings translated. As I understand it, there are two options here, since either a translation is 100% complete or it's not 100% complete:
  • Make it a goal to have some languages get to 100% translated before a new stable branch is released.
  • Don't make it a goal to have some some languages get to 100% translated before a new stable branch is released. This is the current state of things.
The other points I listed are things that I thought might be beneficial for translations to able to be more complete at the time of the stable release. I do not understand why you are saying that the current state is terrible, but then also attack me when I try to come up with ways to improve things.
the development team needs to nurture the most reliable teams, actively show that translations are valued and taken care of to keep and attract new translators and avoid making completed translations without maintainer obsolete.
I do not know how to do this. If I did, this thread would not need to exist in the first place. I am trying to figure out what sort of project-level changes can be made to do this in practice which I can also get at least most of the rest of the people who are part of this project to agree to follow, and you are attacking me for trying.
demario wrote: May 23rd, 2023, 1:08 am
Pentarctagon wrote: May 22nd, 2023, 9:22 pm And I need to understand why, because I need to be able to explain it to other devs when they get frustrated with me telling them they can't do something.
That's the point of making it a rule of "stable branch should have no update of the strings up for translation", you don't have to explain why developers need to do things that way: it is done so because that's the rule. You just need to find a explanation for the exceptions (change in stable branch) that hopefully will be in limited numbers. I see none in octalot's list.
What would an example or two of an exception be then? Does the number of strings changed make any difference? Even if this rule were implemented, I do not want to be back here in a year getting shouted at because we decided something qualified as an exception and you disagree.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
demario
Posts: 131
Joined: July 3rd, 2019, 1:05 pm

Re: [mainline] there is a need for a en_US translation

Post by demario »

Pentarctagon wrote: May 23rd, 2023, 2:10 am
demario wrote: May 23rd, 2023, 1:08 am Who ever asked you to "target certain languages as being 100%"? No one.
You yourself said (bolding mine):
Sticking to your "long-standing policy" makes it impossible for any team to complete full translation at time of release if the new strings are in the high hundreds. Is that your goal for the release of 1.18?
The opposite to make "it impossible for any team to complete full translation" is to make "it possible for any team to complete full translation" and certainly not "target certain languages as being 100% complete before a new stable branch is released" and "releases stalled indefinitely waiting for a translation that has no estimated completion date".

You make it possible by not adding hundreds of fuzzies, a new #wenoth-tools domain (77 strings, 1 month of work) or tens of new elemental units three months before release. In one word, not taking for granted that you can do what you want with translatable strings in development because of your "long-standing policy". That's what I wrote clearly (I think). Anything else is not mine.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

IceSandslash(forums and Discord)/slayer95(github) is doing that in collaboration with Toranks, who is working on Wesnoth's Spanish translation. My understanding is that IceSandslash is also involved in some UMC translations. Some UMC authors on Discord have also said they would find it useful if it could be translated to their language. stevecotton(octalot) also voiced concerns about whether it was worth the additional work for translators, but given a translator was involved in proposing the change we decided it was fine. That PR is not being done by a dev who is clueless about translations - it's very much the opposite.

---
If not, drop the policy and start talking real business.
In response to this, I proposed "Freezing specific areas such as new/overhauled campaigns (such as WoF) early".
At this time some of the most active translations already have 200+ strings on their plate in master branch for core mainline domains only.
If a translation team can only produce 100-150 translated strings per month, they must start working on the master branch to complete translation of a new 800-string campaign for the time of release of the new version. Sticking to your "long-standing policy" makes it impossible for any team to complete full translation at time of release if the new strings are in the high hundreds. Is that your goal for the release of 1.18?.
In response to this, I proposed "No major additions of new strings after a certain point even if there's still not a total string freeze" and "More than 4 months of string freeze before a new stable release". These would also apply to the elementals issue as well.

Are these helpful or not?

---

Lastly, I feel like I do need to state again that regardless, there will be times when there are a large number of string changes. The Dunefolk campaign is not happening for 1.18 due to Wesnoth bugs, but if those are fixed it will still potentially be added for 1.20 because Wesnoth will benefit from adding lore and background for them since they are one of the seven mainline factions. The LoW rework is also delayed, but will hopefully happen eventually because the campaign is currently garbage - it is a failed attempt at a mainline multiplayer campaign because the developer who did it didn't know what they were doing and nobody since has had both the skill and the motivation to fix it. And so on.

I am not approaching this from the perspective that major string changes must not happen. I am approaching this from the perspective that major string changes are sometimes necessary for the improvement of Wesnoth, so what can be done to reduce their impact?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
oooo
Posts: 19
Joined: May 14th, 2014, 12:58 pm
Location: Japan

Re: [mainline] there is a need for a en_US translation

Post by oooo »

I have an idea to free the translators from the release schedule of Wesnoth.

An add-on in Wesnoth 1.16 can add any translation messages if they belong to a new textdomain in a language, but cannot change the existing textdomains. If an add-on could replace some translation messages in any textdomains, the translators can update the translations by an add-on at any time.

If you won't change Wesnoth engine, you can remove MO files except the textdomains for the core user interface and move the translations into an add-on.
User avatar
Pentarctagon
Project Manager
Posts: 5526
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: [mainline] there is a need for a en_US translation

Post by Pentarctagon »

Something that was proposed for a different issue was to have entire campaigns distributed as "official add-ons" (for example: https://github.com/wesnoth/wesnoth/issues/7288).
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
Post Reply