Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

type: Code fence info string should not be translatable #194

Closed
eighthave opened this issue Mar 20, 2020 · 13 comments
Closed

type: Code fence info string should not be translatable #194

eighthave opened this issue Mar 20, 2020 · 13 comments

Comments

@eighthave
Copy link
Contributor

eighthave commented Mar 20, 2020

I cannot think of any instance where the "code fence info string" should be translatable, and least in Markdown syntax. It is as much syntax as the ``` since it is keywords to specify which colorizing syntax to use. For example, in the F-Droid docs, the bash "code fence info string" is split out as a string to translate here. At the very least, there should be an automatically generated comment saying that this rarely translated. Otherwise we will see lots of translations for syntax terms like bash, console, etc. which will break the syntax highlighting

#. type: Code fence info string
#: build/_docs/md/Building_Applications.md build/_docs/md/Build_Server_Setup.md
#: build/_docs/md/Importing_Applications.md
#: build/_docs/md/Installing_the_Server_and_Repo_Tools.md
#: build/_docs/md/Maintaining_the_Forum.md
#: build/_docs/md/Release_Channels_and_Signing_Keys.md
#: build/_docs/md/Setup_an_F-Droid_App_Repo.md
#: build/_docs/md/Signing_Process.md
#: build/_docs/md/Submitting_to_F-Droid_Quick_Start_Guide.md
#, fuzzy, no-wrap
msgid "bash"

Here are some related docs:

@uniqx

@eighthave
Copy link
Contributor Author

@jonassmedegaard looking at the code, it looks like you introduced this feature, so I'm curious to hear your feedback.

@jonassmedegaard
Copy link
Contributor

hi @eighthave - nice to "see" you :-)

Code blocks embedded in markdown files is typically for documentation purposes and sometimes contain locale-specific variables or strings, especially when the "code" really is pseudo-code (which includes listings or similar which isn't really code but visually need vertical alignment of letters).

I therefore find it wrong to completely skip code blocks for translation purposes.

Good suggestion, however, to add a hint to translators alterting them to be cautious not to break code!

@jonassmedegaard
Copy link
Contributor

Here's an example: https://ikiwiki.info/sandbox/

The text "with leading and enclosed spaces" is a code block which would make sense to translate.

Ikiwiki was the original trigger for the code introduction to po4a for handling markdown.

Here's another example where I do translate code blocks (notice the very last line before the footer): https://solidbox.org/setup/index.fr

@jonassmedegaard
Copy link
Contributor

...but perhaps I have totally misunderstood this issue: If you are talking not about the content of code blocks, but only the optional trailing meta hints at the same line as initiating a code block, then I completely agree that it is irrelevant to translate.

@eighthave
Copy link
Contributor Author

I 100% agree that translators should see the contents of the code blocks (see also #195), I'm talking about the "code fence info string", e.g. the "bash" in ```bash from something like:

​```bash
for foo in bar; do
  echo $foo
done
​```

@jonassmedegaard
Copy link
Contributor

then we agree, and I apologize for not reading your initial messages closely!

@eighthave
Copy link
Contributor Author

@jonassmedegaard and hello to you too :-) I'm really terrible at Perl, if you could propose a code snippet here, I could try it out and test it. Looks like removing this line is one piece of the solution: https://salsa.debian.org/mquinson/po4a/-/blob/master/lib/Locale/Po4a/Text.pm#L584

@jonassmedegaard
Copy link
Contributor

jonassmedegaard commented Mar 20, 2020 via email

@jonassmedegaard
Copy link
Contributor

jonassmedegaard commented Mar 20, 2020 via email

@eighthave
Copy link
Contributor Author

That patch works perfectly! I have one small change request: follow the caps standard of po4a and make it "Fenced code block" rather than "fenced code block". This patch solves #194 and #195. Your patch found and properly generated all these:

#. type: fenced code block
#. type: fenced code block (apache)
#. type: fenced code block (bash)
#. type: fenced code block (conf)
#. type: fenced code block (console)
#. type: fenced code block (diff)
#. type: fenced code block (gradle)
#. type: fenced code block (nohighlight)
#. type: fenced code block (python)
#. type: fenced code block (xml)
#. type: fenced code block (yaml)

As for making a merge request, I can make it here on GitHub, or the po4a authors have accepted your merge request on https://salsa.debian.org/mquinson/po4a before, if you want to submit.

@jonassmedegaard
Copy link
Contributor

jonassmedegaard commented Mar 20, 2020 via email

@jonassmedegaard
Copy link
Contributor

@mquinson
Copy link
Owner

Hello,

I cherry-picked the commit from the repo where it was (that is dedicated to the Debian package) and pushed it to the upstream source code on both github and salsa.

Thanks to both of you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants