Page MenuHomeWildfire Games

Escape the backslash within the in-game manual
Needs ReviewPublic

Authored by andy5995 on Aug 6 2018, 11:57 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Trac Tickets
#5272
Summary

Without the preceding backslash, the backslash is not visible within the in-game manual

Test Plan

I'll have to edit this later because I don't know what a "test plan" is.

Diff Detail

Repository
rP 0 A.D. Public Repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

andy5995 created this revision.Aug 6 2018, 11:57 PM
smiley added a subscriber: smiley.EditedAug 7 2018, 3:25 AM

IMO, it would be better to use the escapeText function on https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/gui/manual/manual.js#L5
Because that text file could be read as a text file from elsewhere. Also this is a GUI error when displaying and needs to be fixed there. However, this file is usually read in-game, so there is that too. Maybe someone else can suggest the better of the two.
Edit:: Actually, I think your solution is better. I guess escapeText could mess up the “/n”s.

vladislavbelov added a subscriber: vladislavbelov.EditedAug 7 2018, 10:44 AM

Probably we need to report about unsupported escaped symbols.

elexis added a subscriber: elexis.Aug 7 2018, 11:09 AM

Both approaches have pros and cons.

When using manual escape, it requires translators to never mess up and when changing the escaping mechanism, all text files and translations need to be reviewed and updated.
When using escapeText, it removes the ability to format substrings in text files.

Probably we need to report about unsupported escaped symbols.

You mean unsupported unescaped strings (such as [color="foo"][font="foo"]text[/color][/font])? Seems impossible to detect all cases with code, other than your recent proposal to loading every text string through a test and seeing if there is an error or not. It seems it would be good to write a ticket for the latter then if you can rule out any catches that make it impossible. (It should be a non-visual commandline test, not a GUI page, the according guitag function can be called without displaying it, unless there is a really good reason).

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

^

In D1606#64342, @elexis wrote:

You mean unsupported unescaped strings (such as [color="foo"][font="foo"]text[/color][/font])?

Nope, do we escape strings, not characters? I mean to prevent things like "\ ", when the escaped character does nothing.

It seems it would be good to write a ticket for the latter then if you can rule out any catches that make it impossible. (It should be a non-visual commandline test, not a GUI page, the according guitag function can be called without displaying it, unless there is a really good reason).

To create ticket is good.

After reading the comments, I don't really understand what I should do next, if anything. Sounds like you want to fix this with another method, and need to discuss the best approach? I know it's low priority but just thought I'd touch base in case there's anything else I could do with it at the present time.

To create ticket is good.

I could do this, but again, I didn't really understand what the ticket would be for.