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

Github-flavored Markdown enhancements #69

Open
2 tasks
diegobz opened this issue Mar 8, 2017 · 7 comments
Open
2 tasks

Github-flavored Markdown enhancements #69

diegobz opened this issue Mar 8, 2017 · 7 comments

Comments

@diegobz
Copy link
Contributor

diegobz commented Mar 8, 2017

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
Copy link
Contributor Author

diegobz commented Mar 8, 2017

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

@zeke
Copy link

zeke commented Mar 9, 2017

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
Copy link
Member

kbairak commented Mar 14, 2017

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
Copy link
Contributor Author

diegobz commented Mar 14, 2017

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
Copy link

zeke commented Mar 14, 2017

"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
Copy link
Contributor Author

diegobz commented Mar 15, 2017

@Benau
Copy link

Benau commented Nov 11, 2021

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

Screenshot from 2021-11-11 13-24-55

Currently I have to add newline after each tag to make it appear in transifex, but it kinds of ugly:
Screenshot from 2021-11-11 13-27-37

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

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

4 participants