[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
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 »

a new #wenoth-tools domain (77 strings, 1 month of work)
1 month? What an overstatement. Some languages have already done it in literally negative time (as in the PR is still not merged). As the author of that PR, I can tell you and fellow forum lurkers that if you don't feel that your time is well-invested in translating it, then please use it for your preferred activities. I am confident that whoever finds it useful will eventually take care of it for their own language.

I agree that adding spikes of new translatable strings near releases and simultaneously expecting the translations to be complete on time is untenable. I don't expect them, and that seems to be the case in the current process already. The proposal of blocking string-heavy campaigns/reworks from being merged in some time window looks like good practice to implement. However, that does not imply that no new strings should be added ever to Stable, be it new or existing domain.

Stable only means that breaking changes are guaranteed not to happen for a previously agreed set of features. That means that process can and should be set up for updating strings in Stable, i.e. through the en_US locale only, leaving their msgid untouched. That way, translations are not affected (i.e. no breaking change), according to @demario's OP. Simultaneously, eager translators may accordingly update their work, by fetching the en_US strings. That's a gradualist approach, and that leaves translators room to operate.

More generally, "Stable" absolutism is not good at all. That path means that nothing gets fixed nor improved in Stable, and that all hell breaks loose in "Development". A couple of years down the road, it's not surprising that people complain that next-version (developed without compatibility in mind) is too different from previous-version and that there are unexpected breaking changes, or a large volume of pending translations.

According to this approach:
#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
#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
All these add new strings, so they are fine.
#7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
This one adds new strings, and updates others without significantly impacting the dialogue flow. Therefore, addition to Stable would also be fine, so long as the msgids are not changed.
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).
I had already played Wesnoth on-and-off for nearly 15 years before I decided to browse add-ons. This would severely hurt discoverability.
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.
This is a very good idea. Translators want to get their hands on their finished works ASAP, and they would certainly enjoy making them publicly available as early as possible. For instance, I have recently struggled to explain someone how to install my Spanish translation of To Lands Unknown, in lieu of an official release of that add-on. It must be noted, furthermore, that in order for translations to be viably exposed as add-ons, then stability of strings is expected. At least in the sense I described (new strings allowed, no msgid changes.)
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.
Because of discoverability, I'd prefer for add-ons folder to be checked first as a possible override, but still have default translations for all campaigns packaged with the Wesnoth installation. Also, since there are officially sanctioned campaigns, it also makes sense to have officialy sanctioned translations.
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 23rd, 2023, 6:19 pm
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).
I had already played Wesnoth on-and-off for nearly 15 years before I decided to browse add-ons. This would severely hurt discoverability.
The idea would be that "official add-ons" would be selectable to download in a dialog displayed the first time someone starts Wesnoth. It wouldn't be that Wesnoth would be downloaded with no content and the assumption that people would somehow know to check the add-ons server.

This would make it a lot easier to make most types of changes since add-ons are not updated automatically and also add-ons can be upgraded or downgraded individually within the same branch (stable or dev).
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 »

IceSandslash wrote: May 23rd, 2023, 6:19 pm
#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
#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
All these add new strings, so they are fine.
I disagree that adding new translatable strings to a stable release is "fine". Adding new translatable strings breaks all existing translations. There might be some cases where adding a new translatable string needs to be done in order to fix a critical bug, even in a stable release, but even then it's important to keep in mind that it's going to cause problems for the translations.
IceSandslash wrote: May 23rd, 2023, 6:19 pm
#7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
This one adds new strings, and updates others without significantly impacting the dialogue flow. Therefore, addition to Stable would also be fine, so long as the msgids are not changed.
This I don't understand at all. How would having an en_US translation even help for that particular change? Two new strings were added (one line of dialog and one hint for the player) and two strings were modified. Actually they were modified so extensively that it might be more accurate to say that two strings were removed and four new strings were added. But even if the two affected msgids were preserved, there would still be two new msgids added, so all translations would be broken anyway. The translators would still have to come in and clean up the mess.
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 disagree that adding new translatable strings to a stable release is "fine". Adding new translatable strings breaks all existing translations. There might be some cases where adding a new translatable string needs to be done in order to fix a critical bug, even in a stable release, but even then it's important to keep in mind that it's going to cause problems for the translations.
I think you should have a look at the specific examples listed rather than argue on principle.

Prior to #6966 https://github.com/wesnoth/wesnoth/pull/6966, the English strings were already in the game, but they couldn't be translated at all. That's not going to trouble anybody, unless you mean "I don't wanna do the work" trouble.

#7189 https://github.com/wesnoth/wesnoth/pull/7189 just adds a tooltip, which isn't visible unless you hover over a very specific advanced setting. The only "problem" could be causing a translation to drop from 100% to 99%. Is that something we should care about? I don't think so.

Similarly, #6116 https://github.com/wesnoth/wesnoth/comm ... 1fd1cb689f adds text that should only be visible for content authors.

None of these may even cause a feeling of "Oh, no! The beautiful campaign I worked so hard translating became impure!" Regarding this sentiment, note also that translators already work with the assumption that their PO file might already be stale by the time they email it to ivanovic.
#7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
This one adds new strings, and updates others without significantly impacting the dialogue flow. Therefore, addition to Stable would also be fine, so long as the msgids are not changed.
This I don't understand at all.
So long as you understand my reasoning regarding the other changes, you may then see where do I come from when I claim that preserving both msgids would allow these string updates to qualify for Stable.
Actually they were modified so extensively that it might be more accurate to say that two strings were removed and four new strings were added.
But this is in fact a contentious point, and I'd rather the discussion doesn't get sidetracked into a back-and-forth regarding the best judgment calls for this specific already-merged PR.
gnombat
Posts: 682
Joined: June 10th, 2010, 8:49 pm

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

Post by gnombat »

IceSandslash wrote: May 23rd, 2023, 9:45 pm
I disagree that adding new translatable strings to a stable release is "fine". Adding new translatable strings breaks all existing translations. There might be some cases where adding a new translatable string needs to be done in order to fix a critical bug, even in a stable release, but even then it's important to keep in mind that it's going to cause problems for the translations.
I think you should have a look at the specific examples listed rather than argue on principle.
As I said before, there may be specific cases where it is necessary to introduce a new translatable string to fix a serious bug in a stable release. (I'm not sure any of these really rise to that level, though.)
IceSandslash wrote: May 23rd, 2023, 9:45 pm Prior to #6966 https://github.com/wesnoth/wesnoth/pull/6966, the English strings were already in the game, but they couldn't be translated at all. That's not going to trouble anybody, unless you mean "I don't wanna do the work" trouble.

#7189 https://github.com/wesnoth/wesnoth/pull/7189 just adds a tooltip, which isn't visible unless you hover over a very specific advanced setting. The only "problem" could be causing a translation to drop from 100% to 99%. Is that something we should care about? I don't think so.

Similarly, #6116 https://github.com/wesnoth/wesnoth/comm ... 1fd1cb689f adds text that should only be visible for content authors.

None of these may even cause a feeling of "Oh, no! The beautiful campaign I worked so hard translating became impure!" Regarding this sentiment, note also that translators already work with the assumption that their PO file might already be stale by the time they email it to ivanovic.
Yes, these are all fairly obscure corner cases where 99% of users are probably not likely to ever see the string in question. But not all cases are like that...
IceSandslash wrote: May 23rd, 2023, 9:45 pm
#7291 HttT: not even the hint in the objectives to tell novice players about levelling troops until they get to Siege of Elensefar
This one adds new strings, and updates others without significantly impacting the dialogue flow. Therefore, addition to Stable would also be fine, so long as the msgids are not changed.
This I don't understand at all.
So long as you understand my reasoning regarding the other changes, you may then see where do I come from when I claim that preserving both msgids would allow these string updates to qualify for Stable.
How does your reasoning for the other changes apply here? This isn't some obscure advanced setting buried in the preferences that most users will never see - this is text right in the middle of a campaign (the oldest campaign, probably the most well-known and perhaps the most popular) that any user playing the campaign is going to see. If the translation doesn't get fixed, then suddenly Delfador is going to be talking in a foreign language. Not a good UX.
IceSandslash wrote: May 23rd, 2023, 9:45 pm
Actually they were modified so extensively that it might be more accurate to say that two strings were removed and four new strings were added.
But this is in fact a contentious point, and I'd rather the discussion doesn't get sidetracked into a back-and-forth regarding the best judgment calls for this specific already-merged PR.
My intent is not to argue about whether this change should be merged or not (that's already a fait accompli) but rather to use this change as an example of a typical scenario that translators have to deal with. The question is, if there were an en_US translation, how would that help translators to handle this specific change? As far as I can see, it wouldn't help them at all. Whether the change is treated as 4 strings added + 2 strings removed or 2 strings added + 2 strings modified - either way the translation is going to be broken and it's going to require approximately the same amount of work to fix it. (Note that I'm not actually a translator, though, so it's possible I may be missing something here.)
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 »

If the translation doesn't get fixed, then suddenly Delfador is going to be talking in a foreign language. Not a good UX.
A newcomer getting butchered in Elensefar is also bad UX. The translation can be updated, though, and arguably it should be updated before being released, for the most complete translations. I don't think the least complete translations will care much of yet another instance of bilingualism.

Regarding this issue, I wonder if it would be viable to feature-check translation? Something like

Code: Select all

{VARIABLE src "New string"}
{VARIABLE trans _"New string"}
#textdomain wesnoth-lib
{VARIABLE locale _"language code for localized resources^en_US"}
#textdomain wesnoth-httt
[if]
	[not]
		# Already translated
		{CHECK_VARIABLE trans $src}
	[/not]
	[or]
		# US English locale. String does not need to be changed.
		{CHECK_VARIABLE locale en_US}
	[/or]
	[or]
		# GB English locale. String does not need to be changed.
		{CHECK_VARIABLE locale en_GB}
	[/or]
	[then]
		# Message that may be omitted. But if it's translated,
		# then by all means please show it.
		[message]
			speaker=Delfador
			message=_"New string"
		[/message]
	[/then]
[/if]
example of a typical scenario that translators have to deal with
Granted. Addition of strings to campaigns can be trouble for the most complete translations. It would also be relatively easy to give them a heads up so that they take care of the sporadic new string, and doing so shouldn't be forgotten. So, more communication (again).
if there were an en_US translation, how would that help translators to handle this specific change
The en_US translation addresses string modifications, not additions. So, given that the 2 additions are addressed through communication or feature-checking, then the en_US translation would take care of the 2 modifications.
gnombat
Posts: 682
Joined: June 10th, 2010, 8:49 pm

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

Post by gnombat »

IceSandslash wrote: May 23rd, 2023, 11:26 pm
If the translation doesn't get fixed, then suddenly Delfador is going to be talking in a foreign language. Not a good UX.
A newcomer getting butchered in Elensefar is also bad UX.
Maybe, maybe not ... some people might argue that Elensefar is more a rite of passage for noobs rather than a bug. :twisted: Because I like to think of myself as not being evil, I won't try to argue that case, but I do think the benefits of the change are questionable, while the drawbacks are clear (broken translations) - not a good tradeoff in my opinion.
IceSandslash wrote: May 23rd, 2023, 11:26 pm
if there were an en_US translation, how would that help translators to handle this specific change
The en_US translation addresses string modifications, not additions. So, given that the 2 additions are addressed through communication or feature-checking, then the en_US translation would take care of the 2 modifications.
But if a translator is going to translate the two new strings, then the translator will also have to translate the two modified strings too, because the old translations will probably not make much sense when combined with the new strings. So for #7291 at least there doesn't seem to be any benefit of having an en_US translation at all.

As far as I can see, having an en_US translation would help translators only for very simple string changes, like punctuation changes. But I think in practice most changes are more complex than that.
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 »

But if a translator is going to translate the two new strings, then the translator will also have to translate the two modified strings too, because the old translations will probably not make much sense when combined with the new strings.
The entire point is that if the 2 new strings aren't displayed, and the 2 modified strings keep their msgids, then users of language whatever will still see the old content as if #7291 hadn't happened at all. But when a translator actually goes through the new strings, they will get displayed. The 2 modified strings may not be noticed yet (they require set-variants-fuzzy), but eventually they will get taken care of.

In this specific instance, even if the translation is partial, the result wouldn't be any more strange than if it were fully translated, because the added strings are completely unrelated to their contexts. See:

Before:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
Delfador: 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.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: I did not think the orcs would have come here. This island used to be so beautiful. We must recapture it! To arms!
Half-translated:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: 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.
Delfador: 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.
Delfador: I did not think the orcs would have come here. This island used to be so beautiful. We must recapture it! To arms!
Fully-translated:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: If the orcs have come here, their forces at Elensefar must be even more numerous than I feared..
Delfador: 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.
Delfador: 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!
Now, you may argue that for some language there would actually be something very odd about "Half-translated". With foresight (or closer review of the dialogue), I would have sent the line of Usadar down and back to its original position, so that Half-translated would look like:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
Delfador: 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.
# Delfador's tip as an aside.
Delfador: 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.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: I did not think the orcs would have come here. This island used to be so beautiful. We must recapture it! To arms!
Fully-translated:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
# Usadar doesn't talk/interact with other characters in the story.
Delfador: If the orcs have come here, their forces at Elensefar must be even more numerous than I feared..
Delfador: 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.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: 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!
That would do for the best dialogue flow, since both the new Delfador line and Usadar's line are off-topic in their own. But Delfador's call to arms matches Usadar's, thus making war the topic, as it's supposed to be.

Analysis of #7291 is indeed very fruitful, but let's get something clear. This isn't a typical case. Most miscellaneous string changes are expected to be either additions or changes, not additions, changes, and reorderings. As for larger changes, they are reworks, and most definitely not entering Stable.
gnombat
Posts: 682
Joined: June 10th, 2010, 8:49 pm

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

Post by gnombat »

IceSandslash wrote: May 24th, 2023, 8:15 am Fully-translated:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: If the orcs have come here, their forces at Elensefar must be even more numerous than I feared..
Delfador: 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.
Delfador: 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!
Delfador is making a logical argument here. Orcs have come as far as Alduin. Therefore, they must already have completely overrun Elensefar. Therefore, we must prepare for a big battle in Elensefar.
IceSandslash wrote: May 24th, 2023, 8:15 am Half-translated:

Code: Select all

Konrad: So this is Alduin. It looks a little... desolate.
# Usadar doesn't talk/interact with other characters in the story.
Usadar Q'Kai: Who is that? Oh, a party of elves has landed. We shall drive them back into the sea!
Delfador: 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.
Delfador: 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.
Delfador: I did not think the orcs would have come here. This island used to be so beautiful. We must recapture it! To arms!
This is the problem - when you mix old and new text strings like this, Delfador's chain of reasoning is completely lost. Instead he just mentions "Elensefar" out of the blue in his second text string. What exactly is Elensefar? Why is our journey likely to end there?
IceSandslash wrote: May 24th, 2023, 8:15 am Analysis of #7291 is indeed very fruitful, but let's get something clear. This isn't a typical case. Most miscellaneous string changes are expected to be either additions or changes, not additions, changes, and reorderings. As for larger changes, they are reworks, and most definitely not entering Stable.
That's kind of my point, that complex text changes like #7291 really should be avoided in a stable release if possible.
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 »

The en_US method would not fit the translation add-on method. The en_US method lacks the synchronizing mechanics at run time, it's a serious problem for the translation add-on that is updated independently. The en_US method needs that the deployers make sure to synchronize the original texts and the translated texts in every release, same as the current Wesnoth deployments.

Generally, the gettext uses the original text as the msgid and solves almost all synchronization problems because a bran-new msgid isn't translated at run time. The readers see the correct original text instead of the potentially mistranslated text. It means the players and developers can use an outdated message catalog and the translators have no need to keep watching the project. The en_US method introduced by IceSandslash seems to offer the option to avoid the potentially mistranslation only at build time.

By the way, many add-on creators don't update the existing translation catalog and the transalator updates it rarely, so it uses the run time synchronization.
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 »

The en_US method needs that the deployers make sure to synchronize the original texts and the translated texts in every release, same as the current Wesnoth deployments.
The en_US method introduced by IceSandslash seems to offer the option to avoid the potentially mistranslation only at build time.
Indeed, that would be done through set-variants-fuzzy.
The readers see the correct original text instead of the potentially mistranslated text. It means the players and developers can use an outdated message catalog and the translators have no need to keep watching the project.
Does this correctly fit players expectations? So translators would feel more pressed to keep watch of their addons if they showed outdated strings than if text became plain English?
The en_US method would not fit the translation add-on method.
I am afraid your analysis is mostly correct. It should be theoretically possible to make them fit, though: the add-on ought to distribute the PO files with proper #update translator comments. But actually using that information to ignore outdated strings would be challenging.

Maybe a possible solution would be running set-variants-fuzzy when installing the translation add-on if the add-on has a "refuse outdated translations" flag set. Then, the post install script would be run the first time Wesnoth is opened after being updated, thus performing the synchronization.
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'm not an active translator with Wesnoth, so I would only suggest a way to move the translation catalogs into the add-ons.
IceSandslash wrote: May 24th, 2023, 6:00 pm Does this correctly fit players expectations?
If they know about gettext, they expect it. Otherwise, one of their expectations. I think they expect outdated data are imperfect or corrupt.

Some players claimed untranslation is better than mistranslation, and I think less people like the potentially mistranslated text if they know of a tool to project a translated subtitle with a machine translator, such as PCOT. (This may be an explanation of PCOT in English. https://steamcommunity.com/sharedfiles/ ... 2847675160)
So translators would feel more pressed to keep watch of their addons if they showed outdated strings than if text became plain English?
If I didn't read the discuss here, I would answer YES with confidence, but the translators may have different opinions. *I* am not happy if you use my translation as a mistranslation and you claim it's my creation, but the untranslated text is not my responsibility, yet :whistle: .
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 »

For having just the translations in an add-on, my concern would be that we'd end up with updated translations only getting added to the add-on rather than the main game.

---

For the en_US translation idea, given that at this point:
  • IceSandslash has said they intend to work on implementing this.
  • It doesn't sound like it would cause problems for translators/translation teams who want to use the true text instead of the en_US text.
  • It doesn't sound like there'd be a ton of effort needed to get everything back where it needs to be in case it ends up getting reverted.
then I'd say we might as well try it and see how it goes. At the very least, it doesn't seem like there's any downside to trying.

---

For the topic of "what counts as breaking translations in the stable branch", it seems like there's some consensus that stricter limitations on string changes would be a good change, however not on the degree of strictness. So I'm not sure what, specifically, to do with this yet.

---

And lastly, for the ideas I brought up before:
Pentarctagon wrote: May 23rd, 2023, 3:31 am
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?
doesn't appear to have been discussed further, so my assumption at this point is that they wouldn't be useful.
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
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 »

Pentarctagon wrote: May 27th, 2023, 10:38 pm doesn't appear to have been discussed further, so my assumption at this point is that they wouldn't be useful.
For a topic this complex, I think 5 days without a response is too short a time to draw that conclusion. It's not just that ideas need time to mature, it's also that people with a currently-vague idea may be waiting to see if someone else with a clearer idea will post first.

For example, I'm wondering if a string changed between 1.16.9 and 1.16.10 with a # po_allow_fuzzies: 1.16.9 comment could be passed through the toolchain in such a way that the marked string would show as fuzzy in poedit, but for the languages that had a working translation in 1.16.9 it would be treated as non-fuzzy when building the .mo files. There's a lot of what-ifs there, it's not ready for the complete idea to be posted.
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 »

Pentarctagon wrote: May 27th, 2023, 10:38 pmIn response to this, I proposed "Freezing specific areas such as new/overhauled campaigns (such as WoF) early".
IceSandslash wrote: May 23rd, 2023, 6:19 pmThe proposal of blocking string-heavy campaigns/reworks from being merged in some time window looks like good practice to implement.
My response was regarding the first of Pentarctagon's proposals. The definition of "early" is still an open question, and the authors of the campaigns that are getting reworked for the next stable version should be consulted before suddenly implementing a much earlier deadline. It seems that there's been good progress with NR, recently, for example.
No major additions of new strings after a certain point even if there's still not a total string freeze
This proposal is too generic. I still think the one regarding specific areas is better. Note that translators often divide their work by textdomain, so one major change in one scenario of a mostly-unchanged campaign must be evaluated independently from a full campaign rework/addition.
More than 4 months of string freeze before a new stable release
I am skeptical that freezes exceeding a quarter (i.e. 3 months) would be productive.
# po_allow_fuzzies: 1.16.9 comment could be passed through the toolchain in such a way that the marked string would show as fuzzy in poedit, but for the languages that had a working translation in 1.16.9 it would be treated as non-fuzzy when building the .mo files
This is a fine concept. I can come up with the following up/down-sides. (In parens, comparison with my proposal)

Good - Users
- Unfuzzying done even if the language is abandoned. (Same)
Bad - Users
- Unfuzzying done even if the language is abandoned. Yes, this is both good and bad. But the entire thread depends on the idea that it's more good than bad. (Same)

Good - Translator
- msgid always up to date, with no tools/process involved. (Different)
Bad - Translator
- 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)

Good - Dev
- gettext already has an opinion to whether two strings are changed significatively or not. No need to bikeshed over that if such judgement is accepted. (Lots of discussions so far; gettext's opinion is likely to also be subject to review).
- History of equivalencies browsable in the source code. (Browsable in the PO file).
Bad - Dev
- Verifying that two strings actually fuzzy-match requires additional git checkouts and msgmerge.

(It's possible some of these comparisons become outdated as octalot's proposal evolves.)
Post Reply