Hi! Thanks, your fix looks great. Good to get some structure in there. The question for me is how this holds up for really long lines? If such lines get wrapped into multiple lines in the generated translation, it's not AsciiDoc any more. I'll have to check how that works. And set up a test case for another thing i saw (and worked around) today. Anyhow, I'm happy with the progress we're making. This will be awesome :-) My plan is to keep migrating translated documents over to use po4a, and report problems I encounter. We use a lot of the features in AsciiDoc, which might be a good thing here. /anders

Oops, I found a few more: sect1, sect2, sect3, sect4 preface, colophon, dedication, synopsis, index Seems a lot of different things in AsciiDoc share the same syntax, these are called "section templates" (there's a few more already in our lists): http://www.methods.co.nz/asciidoc/userguide.html#X93 Other uses are "paragraph styles" and "filters". For the case with additional attributes, they are supported for verse and quote, filtered out like so: ($line =~ m/^\[(verse|quote), +(.*)\]$/)) { To try it out I went with this text (as both original and translation): [verse, "William Blake", "from Auguries of Innocence"] To see a world in a grain of sand, And a heaven in a wild flower, Hold infinity in the palm of your hand, And eternity in an hour. Which outputs the following into the po file: #. type: verse #: target/original/src/dummy.asciidoc:4 #, fuzzy, no-wrap msgid "\"William Blake\", \"from Auguries of Innocence\"" msgstr "\"William Blake\", \"from Auguries of Innocence\"" #. type: verse #: target/original/src/dummy.asciidoc:9 #, fuzzy, no-wrap msgid "" "To see a world in a grain of sand,\n" "And a heaven in a wild flower,\n" "Hold infinity in the palm of your hand,\n" "And eternity in an hour.\n" msgstr "" "To see a world in a grain of sand,\n" "And a heaven in a wild flower,\n" "Hold infinity in the palm of your hand,\n" "And eternity in an hour.\n" I think this is good enough, but should be expanded to cover all styles in $asciidoc_RE_STYLE_PARAGRAPH and $asciidoc_RE_STYLE_LIST. And a user contributed list of styles/filters, I guess? (including the different wrapping modes) I'm currently fixing a problem with the current verse/quote + attributes code ... I'll report back regarding that soon. /anders

On 2012/9/27 Anders Nawroth wrote: My understanding so far is that there are two distinct AttributeList usages: inline and block. Inline text is part of msgid, so there is nothing special. The most important usage is when it is a block element. In that case, yes the text enclosed between brackets must not be wrapped. How do we detect block AttributeList? I believe that m/^\[.*\]\s*$/ is quite sane. Asciidoc parser becomes havoc anyway if there are brackets inside brackets, try for instance (my mailer wraps the first line, it must of course not be wrapped) [verse, "William Blake", "from Auguries of Innocence"]and another[verse, "William Blake", "from Auguries of Innocence"] To see a world in a grain of sand, And a heaven in a wild flower, Hold infinity in the palm of your hand, And eternity in an hour. The only special case is with 'verse', because subsequent paragraph must not be wrapped. To handle quotes, we can use } elsif ($asciidoc and not defined $self->{verbatim} and ($line =~ m/^\[(['"]?)(verse|quote)\1, +(.*)\]$/)) { and increment $1 and $2 by 1. So good so far. But if you look at the code just below, it contains special cases to handle icons and captions, to present only translatable text in PO files, without extra markup. If we want to get that far, this is doable but requires more work. If we only want to write bracketed expressions in msgid, this is pretty trivial and can be done very quickly (and in that case I will remove the code to deal with icons/caption). To summarize, there are at least 3 options: 1. Copy [] block attribute lists in msgid as is 2. Extract first positional parameter; this is the msgid type; everything else is put into POT file as attributes on a single line (this is what is currently implemented with verse and quote only) 3. Fully parse attribute lists to handle positional and named parameters; add a mechanism to let users say exactly which arguments are translatable, as is done in the TeX module. Attributes are splitted (and unquoted) and each translatable attribute is written as a single msgid. I believe that 3 is the way to go. (Note to myself: we have to support // comments so that they can be used to give directives to translators). Denis

On 2012/9/27 Anders Nawroth wrote: [...} [...] One quick question: is this valid Asciidoc? I guess so because there are similar examples in documentation, but http://www.methods.co.nz/asciidoc/userguide.html#X21 tells: If the list contains any named or quoted attributes then all string attribute values must be quoted. Here, 'verse' is not quoted. Can you please enlighten me? Denis