Markdown should process lists in paragraphs (and needs tests) about po4a HOT 9 CLOSED

Which formater are you using here? I may well be blind, but it seems to be no Markdown format importer, is it? The first step for a proper MarkDown support is probably to have a dedicated formater, don't you think? As always, PR are warmely welcomed :-P

from po4a.

Which formater are you using here? I may well be blind, but it seems to be no Markdown format importer, is it? The first step for a proper MarkDown support is probably to have a dedicated formater, don't you think?

I have (vague) plans for other improvements in Markdown bullet list handling and noticed this discussion. @mquinson, I'm not sure I understand your comment correctly and wether I should be discouraged to improve the existing Markdown support (in Locale::Po4a::Text) because I would be required to first create a brand new class and think hard about design to avoid too much code duplication.

I would argue that it's best to improve Markdown syntax support in Locale::Po4a::Text as long as these conditions are met:

• the parse_markdown method remains small (currently it is pretty small; compare for example to the asciidoc support that takes about 50% of the SLOC in that class)
• improving support of Markdown syntax incidentally improves parsing of other simple text documents supported by that class; I think this should be easy given staying close to how most people would write text without knowing about Markdown is one design goal of that format; IMO it's already confirmed by the fact we already have pretty good Markdown support with very little Markdown-specific code.

Whenever any of these conditions is not met then I'll be all for creating a dedicated Locale::Po4a::Markdown class but right now I don't really see the point given it would basically be a copy of Locale::Po4a::Text minus the asciidoc, debian/control and fortunes bits.

What do you think?

from po4a.

will a Locale::Po4a::Markdown class:

• strip the markdown from [[!meta title="this is our title"] and generate a mstr= "this is our title"?
• similar with [[!wikipedia Word desc="mydescription"] becoming mstr= "Word" and mstr= "mydescription" in .pot ?
• could maybe verify the existence of internal links?

from po4a.

from po4a.

ok!

from po4a.

I'd be interested to know if this is a case where leveraging another CPAN based markdown processor would be of help. Otherwise, I agree that your criteria for splitting or not splitting look good.

from po4a.

Hello, sorry for the delay.

I totally agree with @intrigeri that support for markdown can grow further in the text parser since it does not harm the text parser in any way for now. When we will have to choose to split the text here or there, depending on whether we assume that it's asciidoc or markdown, then we'll need to consider spliting the parsers. But not for now. So, my first question is now answered.

As for the remark of @bexelbie , I really fail to understand how you could use a regular parser to build a po4a transtractor. I'd be interested in an example ;)

from po4a.

from po4a.

We now have a test case for this, see MarkDown.md in the test directory. From what I can tell, this issue seems to be solved -- the parser generates separate msgids for each bullet point and marks them as being wrappable.

I'm therefore closing this issue, please reopen it if you're missing some functionallity.

from po4a.