[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
octalot
General Code Maintainer
Posts: 777
Joined: July 17th, 2010, 7:40 pm
Location: Austria

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

Post by octalot »

IceSandslash wrote: May 28th, 2023, 4:01 am - If the comment is visible in the PO : "What did it say in 1.16.9?". (Visible after pull-variants; can be integrated in build)
- If the comment is not visible in the PO: Unfuzzying is done without active translators being aware. (Visible after pull-variants; can be integrated in build)
What it said in 1.16.9 would be in the previous text. Suppose that the text in 1.16.9 was "Perhaps I should start at the beginning.", and it was not fuzzy in the German translation of that version. Someone changes the text in the WML, but prefaces it with the magic #po_allow_fuzzies: 1.16.9 comment. The idea would be to patch our workflows that update the .po files, so that this is the result:

Code: Select all

#. [message]: speaker=bar
#: data/foo.cfg:251
#, fuzzy
#, allow_fuzzies_from_1_16_9
#| msgid "Perhaps I should start at the beginning."
msgid "Perhaps I should start at the beginning, for that is a good place to start."
msgstr "Vielleicht sollte ich von vorne beginnen."
Sadly, all unrecognised flags get stripped out when the file is edited with Gettext tools, including the copy of them embedded in Poedit. I might continue with the idea, but would have to insert the record-keeping as part of the previous string.

A change to the workflow would be that whoever does the "pot-update and regenerate doc files" task would pass the version number on the command line, so that # po_allow_fuzzies: 1.16.9 would only trigger special handling when preparing for 1.16.10, and wouldn't be treated specially if it was still in the WML file later.
User avatar
octalot
General Code Maintainer
Posts: 777
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 23rd, 2023, 1:08 am
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.
It's a question of where the compromise between different needs should be. Saying that #6966 shouldn't have been added to stable confuses me, because it only converts strings that were untranslatable to ones that are translatable; that seems a clear case of something that can only improve the situation for players. All the others have some situation where a player who would have seen either a translated string or no string at all will see an English string instead.

#7675 is a similar case where I would expect this to be an improvement in all circumstances, and don't understand a rule that would reject this change. In this case, it's the name of a character and it also appears in surrounding text; in many of the Latin-alphabet languages the name is the same as English, but there's at least 10 languages that change it, and the character gets a speaking role so the name is shown.

#7658 is an attempt to have both "some way to fix strings" while also avoiding breaking existing translations, by showing the old string to players if there isn't a translation of the new string.

IIUC, your rule would reject all of these, but that doesn't seem a good rule to me.
gnombat
Posts: 671
Joined: June 10th, 2010, 8:49 pm

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

Post by gnombat »

octalot wrote: May 30th, 2023, 9:28 pm It's a question of where the compromise between different needs should be. Saying that #6966 shouldn't have been added to stable confuses me, because it only converts strings that were untranslatable to ones that are translatable; that seems a clear case of something that can only improve the situation for players. All the others have some situation where a player who would have seen either a translated string or no string at all will see an English string instead.
There could just be a rule that "Marking a message for translation that was previously not marked for translation by accident" is always allowed, even in stable branches. (Fedora uses that rule for its string freezes.)
demario
Posts: 130
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
  • #6966 WC: Some things that should have been translatable weren't
It's a question of where the compromise between different needs should be. Saying that #6966 shouldn't have been added to stable confuses me, because it only converts strings that were untranslatable to ones that are translatable; that seems a clear case of something that can only improve the situation for players. All the others have some situation where a player who would have seen either a translated string or no string at all will see an English string instead.
Hi octalot, sorry but I don't have time or heart to go into each issue in details.

I hope you see the irony of listing first a WC bug as an urgent string issue that require fixing. The whole inclusion of WC in mainline was a complete mess and the untranslated string was the least of the players' problems (it was not a string critical to the understanding of what the campaign was about). In particular there were numerous WML bugs that ruined the experience of many players but none were enough for the PM to use its own principle that Stable does not mean 100% set in stone and unchanging for absolutely any reason. It seems "stable" means different things for this team based on who is impacted and "stable doesn't mean stable" only applies to translations.

Second, making a string translatable is not solving anything for the players. As long as the translators don't get in and do the actual job, the situation is the same for the players: the string shows in English. That is something that should start to soak in the developers' mind: in terms of translation, only the translators' work matters.

Lastly, Ivanovic himself is against moving back and forth from one branch (master) to another (stable) to apply translation. If some translation work has started to master, switching back to stable to apply a minor change has a high risk of creating a lot of regressions in master if he is not careful. So forcing all teams and Ivanovic to switch back to stable for such a minor thing is bad.

Obviously you solve that by claiming 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. But I showed you that 2 of the most active translation teams have taken upon them to make the bet and have been translating #wesnoth-wof since several months ago. Because there is no other way to get 800+ strings translated in 3 month time. And they will have to do the same thing in the next cycle, where you plan to put three new/redesigned campaigns.
User avatar
octalot
General Code Maintainer
Posts: 777
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 31st, 2023, 1:17 am In particular there were numerous WML bugs that ruined the experience of many players but none were enough for the PM to use its own principle that Stable does not mean 100% set in stone and unchanging for absolutely any reason.
The reason for a different rule there is the Out Of Sync error - OOS breaks the game and means the players have to quit, reload, and hope that reloading gets everyone onto the same state. That lead onto the discussion in #7288, and the complex workaround instead of directly fixing the bugs.

I've asked Ivanovic if he can help clarify, but commenting on the OOS-related issues doesn't help me understand why translations would be similar.
User avatar
Celtic_Minstrel
Developer
Posts: 2158
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

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

Post by Celtic_Minstrel »

demario wrote: May 31st, 2023, 1:17 am Second, making a string translatable is not solving anything for the players. As long as the translators don't get in and do the actual job, the situation is the same for the players: the string shows in English. That is something that should start to soak in the developers' mind: in terms of translation, only the translators' work matters.
Based on this argument, there should be no issue with marking a string translatable in stable that was previously not translatable. It has no net immediate change, but should the translator for a language choose to take the time to add a translation, it is an improvement. And if the translator decides it's not worth updating stable just for that one string, then it's still no net change and there's no issue.
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
User avatar
ivanovic
Lord of Translations
Posts: 1149
Joined: September 28th, 2004, 10:10 pm
Location: Germany

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

Post by ivanovic »

demario wrote: May 31st, 2023, 1:17 am Lastly, Ivanovic himself is against moving back and forth from one branch (master) to another (stable) to apply translation. If some translation work has started to master, switching back to stable to apply a minor change has a high risk of creating a lot of regressions in master if he is not careful. So forcing all teams and Ivanovic to switch back to stable for such a minor thing is bad.
Small correction here:
What I usually do when a translation team is working exclusively on stable is to apply the changes to both, stable and dev. This way the improvements during stable will automatically be waiting for the translation team once they do the switch over to dev. I recommend to do this switch once it is clear that the development will "soon" become the next stable release. When I receive translations it is ALWAYS full files since this minimizes the risk of issues. I insist on getting full files which I then merge against the latest available translation catalog.

If I just took the translation files from a further progressed dev and applied that to stable, a lot of previously translated strings would become untranslated (not good, this would be a regression) since they are added/changed in the latest translation catalog. Because of this once the translation team starts to work on dev (beyond completely new text domains), the translation team will have to take care of the two branches in parallel to ensure that the stable translation does not "lose translated strings". This is what the teams normally do when they decide to switch to dev since in that situation stable is usually "basically complete" so only typo fixes happening to stable need to be implemented.

In case of "completely new domains" the translation team can of course already start the work on that domain and only send in that file as separate update for dev stating that the files from stable can still be applied to dev in addition. No problem with that at all.

Lastly two additional points:
  • Any translated string is there due to the effort by a translation team. If the string is in basic english, then the respective translation team did not get to it yet.
  • A translation should NEVER lead to an OOS error since it should only be a "UI replacement", nothing under the hood.
demario
Posts: 130
Joined: July 3rd, 2019, 1:05 pm

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

Post by demario »

ivanovic wrote: June 3rd, 2023, 9:47 am Small correction here
Thank you Ivanovic for the clarifications.
  • translation team is working exclusively on stable

    That should be the default situation during the early development and changes are applied to both, stable and dev.
  • In case of "completely new domains" [in dev branch], the translation team can of course already start the work on that domain and only send in that file

    So working early on the dev branch for new textdomains is actually the standard process. That meets the requirement that domains with several hundreds of new translatable strings can't be completed within the 3-month "string freeze".
  • the teams decide to switch to dev since in that situation stable is usually "basically complete" so only typo fixes happening to stable need to be implemented.

    I understand that the situation stable is usually "basically complete" is a criteria that is specific to each translation (not dependent on the general situation of translatable strings in stable). If so, the decision to switch to dev branch is for the translation teams to make. So working in dev branch is actually allowed by the standard process rather than "the dev branch shouldn't be the target of any translation team". It is the responsibility of the development team to make this process work.
  • If I just took the translation files from a further progressed dev and applied that to stable, a lot of previously translated strings would become untranslated (not good, this would be a regression) since they are added/changed in the latest translation catalog. Because of this once the translation team starts to work on dev (beyond completely new text domains), the translation team will have to take care of the two branches in parallel to ensure that the stable translation does not "lose translated strings".

    I understand this as an official confirmation that, after some teams have decided to switch to dev branch, subsequent changes in stable are hurtful and dangerous. This should definitely close the window for update of any translatable string in stable.
I think this break-down of the problem still misses some important cases:
  • heavily modified existing text domain from campaign rework.

    As it can involved hundreds of string changes, it should be possible that the translation is started early like new domains.
  • specific case of the #wesnoth-units domain.

    As one of the most visible domains, it often leads to update from lore, flavor or stats update. And it is also heavily updated to add new units (that are not part of the original set of units found in MP eras). I have expressed before that these units should get their new text domain (elementals...).
Soliton
Site Administrator
Posts: 1678
Joined: April 5th, 2005, 3:25 pm
Location: #wesnoth-mp

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

Post by Soliton »

demario wrote: June 8th, 2023, 1:33 am
  • In case of "completely new domains" [in dev branch], the translation team can of course already start the work on that domain and only send in that file

    So working early on the dev branch for new textdomains is actually the standard process. That meets the requirement that domains with several hundreds of new translatable strings can't be completed within the 3-month "string freeze".
"can of course already start" means that translation teams can already start on the dev branch. There is zero implication that this is a good idea nor that that is the standard process. It is merely simple to handle because it's a file that only exists in dev.
demario wrote: June 8th, 2023, 1:33 am
  • the teams decide to switch to dev since in that situation stable is usually "basically complete" so only typo fixes happening to stable need to be implemented.

    I understand that the situation stable is usually "basically complete" is a criteria that is specific to each translation (not dependent on the general situation of translatable strings in stable). If so, the decision to switch to dev branch is for the translation teams to make. So working in dev branch is actually allowed by the standard process rather than "the dev branch shouldn't be the target of any translation team". It is the responsibility of the development team to make this process work.
"the dev branch shouldn't be the target of any translation team" means that translation teams shouldn't target the dev branch. It does not mean they are not allowed to. If they do it then the expectation should be that the work may be lost by future string changes in the course of development.
demario wrote: June 8th, 2023, 1:33 am
  • If I just took the translation files from a further progressed dev and applied that to stable, a lot of previously translated strings would become untranslated (not good, this would be a regression) since they are added/changed in the latest translation catalog. Because of this once the translation team starts to work on dev (beyond completely new text domains), the translation team will have to take care of the two branches in parallel to ensure that the stable translation does not "lose translated strings".

    I understand this as an official confirmation that, after some teams have decided to switch to dev branch, subsequent changes in stable are hurtful and dangerous. This should definitely close the window for update of any translatable string in stable.
What Ivanovic said means that translation teams need to handle translations for stable and dev separately and tell him for the translations they send in if they are for stable or dev. Because if they send in a translation for dev and don't tell Ivanovic so that he applies it to stable then that is "hurtful and dangerous". This is completely unrelated to what string changes should be done in stable.
"If gameplay requires it, they can be made to live on Venus." -- scott
demario
Posts: 130
Joined: July 3rd, 2019, 1:05 pm

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

Post by demario »

Soliton wrote: June 8th, 2023, 2:24 pm "can of course already start" means that translation teams can already start on the dev branch. There is zero implication that this is a good idea nor that that is the standard process. It is merely simple to handle because it's a file that only exists in dev.
Ivanovic didn't take a break from its nearly retirement from wesnoth just to state banalities about what translators can possibly do.
He has come, at the request of one of your fellow developer, to clarify the "rules" that applies to the standard process for inclusion of translator work into the wesnoth product. As your own PM has stated, basically no one else in the team has a grasp on this topic. You could have used this chance to learn something. Instead you come with your pseudo linguistical analysis of the shortest message Ivanovic could afford to write, without any understanding of the big picture.
What a waste of an opportunity.
Soliton wrote: June 8th, 2023, 2:24 pm "the dev branch shouldn't be the target of any translation team" means that translation teams shouldn't target the dev branch. It does not mean they are not allowed to. If they do it then the expectation should be that the work may be lost by future string changes in the course of development.
Ivanovic has not repeated the mantra "the dev branch shouldn't be the target of any translation team" that you guys keep invoking. I developed how what he said is actually a departure from that "rule". Obviously you missed the point, stuck as you are in the justification of your own "being always right".
Soliton wrote: June 8th, 2023, 2:24 pm What Ivanovic said means that translation teams need to handle translations for stable and dev separately and tell him for the translations they send in if they are for stable or dev. Because if they send in a translation for dev and don't tell Ivanovic so that he applies it to stable then that is "hurtful and dangerous". This is completely unrelated to what string changes should be done in stable.
If you understood better the topic, you would know that most of the translators are not tech-savvy persons (there are exceptions, of course). When Ivanovic says translators should be careful, he basically means that this is not suitable for most teams. Given that his time is limited, he also personally want to avoid any situation that would require him to spend extra amount of time to do things with special care. That is an information he passed to me (as translator), and I guess he did to other people when he is not aware of their personal technical skill.

You're not guilty for not being familiar with the topic, but why on earth did you feel like you should pretend being a reference that needs to clarify things?
User avatar
Celtic_Minstrel
Developer
Posts: 2158
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

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

Post by Celtic_Minstrel »

demario wrote: November 11th, 2023, 7:33 am Ivanovic has not repeated the mantra "the dev branch shouldn't be the target of any translation team" that you guys keep invoking. I developed how what he said is actually a departure from that "rule". Obviously you missed the point, stuck as you are in the justification of your own "being always right".
I don't think anything Ivanovic said is in contradiction to the idea that translation teams generally shouldn't target the dev branch. There might be exceptions, sure – completely new textdomains, for example.
demario wrote: June 8th, 2023, 1:33 am I understand this as an official confirmation that, after some teams have decided to switch to dev branch, subsequent changes in stable are hurtful and dangerous. This should definitely close the window for update of any translatable string in stable.[/list]
This statement seems to imply that translators get to decide when strings are frozen. That doesn't make any sense.
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
User avatar
ivanovic
Lord of Translations
Posts: 1149
Joined: September 28th, 2004, 10:10 pm
Location: Germany

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

Post by ivanovic »

Guess I need to jump in to make sure that I am not too badly misunderstood. ;)

The thing is that after my post Soliton was spot on. For most translation teams it is not worth the extra effort to work on the translations of the dev branch until the "owners of the content" state that they are ready for it. Usually that is the case once the development team declares the string freeze which should last for several weeks and should be announced (e.g., by mail).

But of course you are also right, demario, translations can be a ton of work which requires time to complete and it hurts to re-do that work again and again. That is why I pushed in the past to NOT do major reworks of campaigns within the stable branch but keep those in the dev tree and provide input when the content owner is done. The problem is, if you as translation team switch to working on those in dev, you will be "out of sync" with the work in stable and have to maintain both branches for yourself since there can (and likely will) still be bugfixes (usually grammar and typos but sometimes also logics) in stable.

What this means:
  • The translation teams should first focus on stable (same Soliton pointed out) --> I would focus on this with the highest priority since even between the different stable branches (1.14 -> 1.16) a lot of content can be reused
  • With major new content it makes sense to start work on dev "early" if the team has some "free capacity" (but make sure to try to find out from the dev team if the content is already okay to start on!) --> I would give it a lower priority than "completing" stable
  • Translation teams are absolutely free to keep both stable and dev at "mostly complete" state but have to be aware that the work on dev can easily be wasted and extra effort is required since the branches have to be maintained in parallel
  • Best time for translation teams to switch from stable over to development is when the initial stringfreeze for the dev branch to become a new stable series is announced by the dev team: This gives you the most time to get the work done in time before a new stable is created but means that larger changes (beyond bugfixes) are unlikely, so work will not be lost --> after the initial string freeze is started, I would treat dev as the new stable and exclusively switch work to it
These "guidelines" (not hard rules!) are there to minimize the frustration of the translators involved because if major changes happen (which are the intent of a dev branch!), large parts of work might be wasted. If a campaign suddenly loses some scenarios and a translator already worked on those, they are likely to be unhappy. In the end every decision is up to the translation team. But you should know what you get into when working on dev "early" in the development cycle to not get frustrated with the normal progression of game development.

And yeah, of course it is important that when a team sends me a translation they tell me if this update is for both, stable and dev, or only for one of the branches since it is near impossible to keep track of which teams are working on which branches already. ;)
demario
Posts: 130
Joined: July 3rd, 2019, 1:05 pm

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

Post by demario »

But of course you are also right, demario, translations can be a ton of work which requires time to complete and it hurts to re-do that work again and again.
As the opening post highlights, there are different situations that can lead to frustration in the translation teams.
This includes:
  • incessant flavor/syntax/typographic changes in the original English text that breaks translation
  • thousands of unannounced new strings while translators are fighting to complete a couple of hundreds of translated strings
  • repeated reviews and changes to strings in development branch
It seems like the development team likes to repeatedly focus on the third type. Mmm, wonder why this is... Could it be that they can brainlessly use their ready-made retort (guess what? it is the translators' fault, stupid!)
  • The translation teams should first focus on stable
Several circumstances can impede this activity:
  • translation already complete
  • the strings are targeted to change in the next roadmap, meaning the translation would be made obsolete on next version
  • too close to the release of the new version to be worth.
How much translation activity have you seen in stable branch in the last 6 months?
  • be aware that the work on dev can easily be wasted
During the whole run of this thread none of the developers was willing to make any of these statements:
  • extensive translations are good for wesnoth
  • loss of translation make wesnoth worse
  • translators should be given opportunities to reach their full potential in translation coverage
The development team ask for freedom in dev branch. But freedom comes with responsibilities.
If they don't feel responsible to work around translation following these 3 principles, the freedom they claim is just childish entitlement.
User avatar
Pentarctagon
Project Manager
Posts: 5496
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

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

Post by Pentarctagon »

Getting better at following Wesnoth's Style Guide, catching typos, etc is something we know we need to do better (#7967). But if you start translating the development branch without first discussing what you plan to start translating with the development team, then you will quite likely end up with some rework.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
Celtic_Minstrel
Developer
Posts: 2158
Joined: August 3rd, 2012, 11:26 pm
Location: Canada
Contact:

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

Post by Celtic_Minstrel »

demario wrote: November 21st, 2023, 8:13 pm just childish entitlement.
Hmmmm… :whistle:
Author of The Black Cross of Aleron campaign and Default++ era.
Former maintainer of Steelhive.
Post Reply