Page MenuHomeWildfire Games

manual/intro.txt corrections
ClosedPublic

Authored by Nescio on Jul 22 2019, 1:09 PM.

Details

Reviewers
Gallaecio
elexis
Itms
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Commits
rP22904: manual/intro.txt corrections
Summary

Another follow-up to D1719 and D1744. This one does the following:

  • [font="sans-14"] (default) at the end of the line that used a different font, rather than at the beginning of the next line (no net change, but looks better in the file)
  • two spaces for indentation of hotkeys (looks better in game)
  • (space en-dash space) instead of : (colon space) to separate hotkey and description, for better visibility and consistency.
  • 6400px by 4800px6400×4800 pixels
  • removed Alt+W entry (superseded by Alt+Shift+W above)
  • inserted Esc entry under save game for completeness
  • rephrased several descriptions

Before:


After:

Test Plan

Launch the game and open the manual.

Diff Detail

Repository
rP 0 A.D. Public Repository
Branch
/ps/trunk
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8930
Build 14657: Vulcan BuildJenkins
Build 14656: arc lint + arc unit

Event Timeline

Nescio created this revision.Jul 22 2019, 1:09 PM
Owners added a subscriber: Restricted Owners Package.Jul 22 2019, 1:09 PM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/183/display/redirect

Nescio updated this revision to Diff 9054.Jul 22 2019, 1:26 PM

Display backslash (\ won't show up, \\ does) and add names of other punctuation symbols for better visibility.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/184/display/redirect

Not implemented, but worth considering: use (space en-dash space) instead of : (colon space) to separate hotkey and description, e.g.

Nescio added a reviewer: Restricted Owners Package.Aug 7 2019, 10:57 AM
Nescio updated this revision to Diff 9328.Aug 15 2019, 9:43 AM

Updated because of rP22650.

Nescio updated this revision to Diff 9331.Aug 15 2019, 9:47 AM
Nescio edited the summary of this revision. (Show Details)

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/377/display/redirect

Nescio updated this revision to Diff 9333.Aug 15 2019, 9:50 AM

ESCEsc

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/379/display/redirect

Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/380/display/redirect

I’ve left a comment regarding font tags.

I’m unsure about the spaces at the beginning, but I don’t have strong feelings against it, so +1.

As for the rest of the changes, I like all of them, they all seem for the better.

binaries/data/mods/public/gui/manual/intro.txt
1

I disagree.

For translators, in general, whenever a font tag can be in a line of its own, it should.

Because we get strings from here on a line-by-line basis, having tags in their own lines allows us to ‘translate’ (copy and paste) each tag only once (we only translate repeated lines once), and give us clean, tagless strings for the actual translatable lines.

As for the font tags, I don't fully understand your point. The number of tags remains unchanged. What this patch does is instead of having one font tag in two lines, e.g.

[font="sans-bold-16"]Modes
[font="sans-14"]The main menu gives access to two game modes:

it is changed to two font tags in one line, e.g.

[font="sans-bold-16"]Modes[font="sans-14"]
The main menu gives access to two game modes:

to be consistent with e.g.

• [font="sans-bold-14"]Multiplayer[font="sans-14"] – play against human opponents over the internet.
In D2110#90707, @Nescio wrote:

As for the font tags, I don't fully understand your point. The number of tags remains unchanged. What this patch does is instead of having one font tag in two lines, e.g.

What I think @Gallaecio meant is that translators get the text per line. So:

[font="sans-bold-16"]Modes
[font="sans-14"]The main menu gives access to two game modes:

as:

[font="sans-bold-16"]Modes

[font="sans-14"]The main menu gives access to two game modes:

and one has to copy-paste the font tags, for every line using it, even though the tags itself may be the same.

When that would be changed to:

[font="sans-bold-16"]
Modes
[font="sans-14"]
The main menu gives access to two game modes:

The tags which occur at multiple places are translated autmatically (since it's exactly the same string) and the translators only need to worry about the actual text. I do not know however if having a font tag solely on a line will trigger an paragraph break?

In D2110#90707, @Nescio wrote:

to be consistent with e.g.

• [font="sans-bold-14"]Multiplayer[font="sans-14"] – play against human opponents over the internet.

But there the font changes within one sentence and would be different I guess.

[font="sans-bold-16"]
Modes
[font="sans-14"]
The main menu gives access to two game modes:

This means four lines, two of which show up as white lines in game; cf.


with

Those extra white lines are undesirable.

In D2110#90731, @Nescio wrote:

Those extra white lines are undesirable.

Then it's obviously a no-go ;)

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/390/display/redirect

I meant what @Freagarach said, and as I suspected is a no-go.

I have no strong opinion on the tag changes; if someone else agrees with them, let’s go ahead. Otherwise, let’s keep them as before to minimize string changes.

I have no strong opinion on the tag changes; if someone else agrees with them, let’s go ahead. Otherwise, let’s keep them as before to minimize string changes.

In mark-up languages it's customary to close tags on the same line, e.g. LaTeX \textbf{lorem}, HTML <b>ipsum</b>, MarkDown **dolor**, hence my preference for [font="sans-bold-14"]sit[font="sans-14"] in this text file, which also makes it easier to see if a tag is forgotten.

Something else:

Not implemented, but worth considering: use (space en-dash space) instead of : (colon space) to separate hotkey and description.

Gallaecio accepted this revision.Aug 18 2019, 2:43 PM
In D2110#90945, @Nescio wrote:

I have no strong opinion on the tag changes; if someone else agrees with them, let’s go ahead. Otherwise, let’s keep them as before to minimize string changes.

In mark-up languages it's customary to close tags on the same line, e.g. LaTeX \textbf{lorem}, HTML <b>ipsum</b>, MarkDown **dolor**, hence my preference for [font="sans-bold-14"]sit[font="sans-14"] in this text file, which also makes it easier to see if a tag is forgotten.

However here we are talking of making opening tags look like closing tags. But I guess it does look better. And, come to think of it, as a translator this will reduce to a half the number of strings that contain tags, so I guess it can be seen as an improvement.

Something else:

Not implemented, but worth considering: use (space en-dash space) instead of : (colon space) to separate hotkey and description.

Whichever you prefer, both look good to me.

This revision is now accepted and ready to land.Aug 18 2019, 2:43 PM

as a translator this will reduce to a half the number of strings that contain tags

But if tags were all on the same line, it would reduce it even further, so that the font only has to be translated once per font?

Gallaecio added a comment.EditedAug 18 2019, 3:23 PM
In D2110#91004, @elexis wrote:

as a translator this will reduce to a half the number of strings that contain tags

But if tags were all on the same line, it would reduce it even further, so that the font only has to be translated once per font?

Yes, that’s what I hoped for, but that is not possible without introducing undesired additional line breaks. While we could do it for some of the tags, the text would then look inconsistent.

Unless we make [font="sans-bold-14"] eat up a line break when followed by one (or something in those lines), so when they are in their own line it does not count as a line break, I don’t think the most translator-friendly approach is viable. And modifying how the font tag affects line breaks would require us to carefully review all its usages.

If one doesn't use \n\n stylistically, one could do the following:

Index: binaries/data/mods/public/gui/manual/manual.xml
===================================================================
--- binaries/data/mods/public/gui/manual/manual.xml	(revision 22681)
+++ binaries/data/mods/public/gui/manual/manual.xml	(working copy)
@@ -15,7 +15,10 @@
 
 		<object type="image" sprite="ModernFade" size="20 20 100%-20 100%-58">
 			<object name="mainText" type="text" style="ModernTextPanel">
-				<action on="Load">this.caption = Engine.TranslateLines(Engine.ReadFile("gui/manual/intro.txt"));</action>
+				<action on="Load">
+					// Strip lines that only have a font tag
+					this.caption = Engine.TranslateLines(Engine.ReadFile("gui/manual/intro.txt")).replace(new RegExp('\n\n','g'), "\n");
+				</action>
 			</object>
 		</object>

Or perhaps only the \n\n\n ones, since sentence1\n\nsentence2 would remove the separating newline.
Meh, doesn't work right.

One could mess with CGUIString.cpp parsing too, but it sounds wrong going there.

However here we are talking of making opening tags look like closing tags.

I'm not so fond of that either.

Looking at

[font="sans-bold-16"]Hotkeys:[font="sans-14"]
[font="sans-bold-14"]Program-wide[font="sans-14"]

The idea is that the opening tag is now purposed as the closing tag.

Perhaps in the long run it might be nice to transform this into a JSON file, so that the styling (including indentation and ) is removed from the strings.

I didn't say anything.

Nescio updated this revision to Diff 9379.Aug 18 2019, 4:16 PM
Nescio edited the summary of this revision. (Show Details)

Replaced : (colon space) with (space en-dash space) for consistency and better visibility.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/412/display/redirect

Freagarach added inline comments.Aug 19 2019, 10:08 PM
binaries/data/mods/public/gui/manual/intro.txt
10–20

AI opponents -> computer controlled (AI)? Or something. I'm not sure AI is widely known as computer controlled.

39–157

The last font is not necessary, because the font is changed again on the next line.

103

Wow :) I did not know that one ;)

143

to stop following the unit?

146

Hyphen may be more correct, but it is understandable? I think most people just think of it as a minus. I'm okay with this though.

Nescio updated this revision to Diff 9407.Aug 19 2019, 11:34 PM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/430/display/redirect

Freagarach added inline comments.Aug 20 2019, 8:14 AM
binaries/data/mods/public/gui/manual/intro.txt
39

Do you have any specific reason to keep it (the second font-tag)?

Nescio added inline comments.Aug 20 2019, 9:37 AM
binaries/data/mods/public/gui/manual/intro.txt
39

Yes, using opening font tags for closing different fonts is not ideal, but it is at least internally consistent in this file.
If you now do a Ctrl+F for font you'll get an even number and Ctrl+F for font="sans-14" gives half that number, which makes it easy to check no font tags are forgotten.

@elexis May I merge?

See our last IRC discussion, committing patches that you deem correct is your task description, even more so when both of you agree and noone objected.

Whether I would commit or accept the same patch is a different question. Perhaps its possible to find a better solution for the start/end tag thing, IIRC it would have to be in JSON, so thats out of immediate reach and the patch might not make things worse.

Also if I am enlisted as a reviewer of a patch, that doesn't mean anything as that might be the case for uncounted patches.
(Really, don't ask me for permission, if anything you can ask me for objections, we should be peers and commit things that we think are right and account for objections if they were voiced but not have to ask for permission. As far as Im considered you are the head of the internationalization department or did I miss something? )

This revision was automatically updated to reflect the committed changes.