Github-flavored Markdown enhancements

[diegobz]

I'm opening this ticket to track improvements we need to make to the parser.

Here a list of things we still need to accomplish:

• Make sure extracted strings are escaped correctly.
• Use proper YAML parser to handle Jekyll's Front Matter data.

Design decisions we need to make:

1. What YAML attr should be translatable?
2. Should HTML content be supported?
3. Do we extract a whole table as a string or just each cell content in separate strings?
4. Code block should be extracted or not?

[diegobz]

@kbairak @zeke Just to start keeping track of stuff.

[zeke]

These are important questions to which I don't know the answer. :)

What YAML attr should be translatable?

All of them, I think. Frontmatter values should be subjected to the same validation process that other content is, in that {{ }} blocks should be protected.

Should HTML content be supported?

Unfortunately I would say yes, because markdown allows any and all HTML. HTML content is often used to do layout stuff that can't be achieved with markdown.

Do we extract a whole table as a string or just each cell content in separate strings?

Each cell, I would think.

Code block should be extracted or not?

Tough question. Even if it is not editable, it should at least be displayed to the translator for context.

Maybe the ideal would be something that is able to detect comments in code. That sound really hard though!

[kbairak]

Hey everyone,

Code block should be extracted or not?

Tough question. Even if it is not editable, it should at least be displayed to the translator for context.

In Transifex, context is something applied to strings, so If we consider code blocks to be context, which string do we apply it to? The one preceding? I guess that this is as good a choice as any so if we are satisfied with that, it can be done.

[diegobz]

Code block should be extracted or not?

Tough question. Even if it is not editable, it should at least be displayed to the translator for context.

In Transifex, context is something applied to strings, so If we consider code blocks to be context, > which string do we apply it to? The one preceding? I guess that this is as good a choice as any so if we are satisfied with that, it can be done.

@kbairak I think "context" on @zeke's comment was more related to being able to read the whole document in order in the editor with no important piece of info missing. I think this is important too.

I'm thinking that by default we should probably extract it and make it available for translations, then have validation checks that can ensure it doesn't break the md formatting.

We also have validation checks that can be applied to strings based on tag they receive. If people want to make the code block strings not editable, then we could suggest doing an extra step and use our API to apply the notranslate tag for given strings.

String type could be identified easily if we populate the context field of the string with such info. Example, paragraph, list_item, quote, code_block, header1, etc...

[zeke]

"context" [...] was more related to being able to read the whole document in order in the editor with no important piece of info missing.

👍

[diegobz]

BTW https://githubengineering.com/a-formal-spec-for-github-markdown/

[Benau]

Hello,
Do you think you can support translatable content inside liquid tag:

Currently I have to add newline after each tag to make it appear in transifex, but it kinds of ugly:

And it makes pseudo translation failed for my markdown file

Do you think my approch looks fine to you (using front matter to tell which liquid tag should enable translation as shown in first screenshot)? if so I can do the python part in openformat