[mainline] there is a need for a en_US translation
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
Re: [mainline] there is a need for a en_US translation
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 magicIceSandslash 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)
#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."
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.Re: [mainline] there is a need for a en_US translation
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.demario wrote: ↑May 23rd, 2023, 1:08 amI am not sure what you're asking.octalot wrote: ↑May 22nd, 2023, 4:12 pmWhich 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.
- #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
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.
#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.
Re: [mainline] there is a need for a en_US translation
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.)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.
Re: [mainline] there is a need for a en_US translation
Hi octalot, sorry but I don't have time or heart to go into each issue in details.octalot wrote: ↑May 22nd, 2023, 4:12 pmIt'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.
- #6966 WC: Some things that should have been translatable weren't
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.Re: [mainline] there is a need for a en_US translation
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.
- Celtic_Minstrel
- Developer
- Posts: 2274
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: [mainline] there is a need for a en_US translation
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.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.
Re: [mainline] there is a need for a en_US translation
Small correction here: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.
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.
Re: [mainline] there is a need for a en_US translation
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 thesituation 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.
- 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...).
Re: [mainline] there is a need for a en_US translation
"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
- 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 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
- 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 thesituation 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.
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.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.
"If gameplay requires it, they can be made to live on Venus." -- scott
Re: [mainline] there is a need for a en_US translation
Ivanovic didn't take a break from its nearly retirement from wesnoth just to state banalities about what translators can possibly do.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.
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.
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 "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.
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.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.
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?
- Celtic_Minstrel
- Developer
- Posts: 2274
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: [mainline] there is a need for a en_US translation
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: ↑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".
This statement seems to imply that translators get to decide when strings are frozen. That doesn't make any sense.
Re: [mainline] there is a need for a en_US translation
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:
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.
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
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.
Re: [mainline] there is a need for a en_US translation
As the opening post highlights, there are different situations that can lead to frustration in the translation teams.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.
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 is the translators' fault, stupid!
)
Several circumstances can impede this activity:
- The translation teams should first focus on stable
- 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.
During the whole run of this thread none of the developers was willing to make any of these statements:
- be aware that the work on dev can easily be wasted
- 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
If they don't feel responsible to work around translation following these 3 principles, the freedom they claim is just childish entitlement.
- Pentarctagon
- Project Manager
- Posts: 5592
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: [mainline] there is a need for a en_US translation
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
take one down, patch it around
-2,147,483,648 little bugs in the code
- Celtic_Minstrel
- Developer
- Posts: 2274
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact: