New po4a release coming soon
by D. Barbier
Hello,
I will give a talk about po4a at the end of November, it may include new
features like Asciidoc. So I want to make a new release before that date.
Here is my current planning:
* Now: bugfixes and proofreading of documentation
* Sunday, 12 Nov: string freeze
* Wed, 21 Nov: release
I just updated PO files; please review the new strings and help me to
improve documentation.
Thanks!
Denis
12 years, 11 months
po4a 0.43 has been released
by D. Barbier
Hello,
I am pleased to announce the release of po4a 0.43.
* Major changes in release 0.43 (2012-10-17)
po4a:
* Add --porefs option to change how file locations are written into
the POT file (and thus into the PO files also).
po4a-updatepo po4a Po:
* Extend the --porefs option, add a new 'counter' value to replace
line number by an increasing counter.
An optional ",nowrap" or ",wrap" specifier can be added to tell
whether file locations are written on a single line or wrapped on
several lines. Default is ",nowrap", it will be changed to ",wrap"
in a future release.
Man:
* Make .UR/.UE macros inline.
* Add macros used in several NetBSD man pages: %I %U Brc Bro Lp Lk
Text:
* Fix two line titles in AsciiDoc format.
* Let AsciiDoc format handle many more styles.
* Add support for automatic comments in AsciiDoc format.
Many thanks to all people who contributed to this release.
Denis
13 years
macros in AsciiDoc
by Anders Nawroth
Hi!
I think it was already mentioned in some thread, but I couldn't find it ...
AsciiDoc block macros need special treatment.
They can appear inside a paragraph, but still need to be on their own line
to be parsed correctly.
For example (from the AsciiDoc User guide):
ifdef::revnumber[]
Version number 42
endif::revnumber[]
That will work, but po4a will alter it into:
ifdef::revnumber[] Version number 42 endif::revnumber[]
which will not be parsed correctly any more.
Maybe paragraphs containing block macros could be
marked as no-wrap?
/anders
--
Anders Nawroth [anders(a)neotechnology.com]
Skype: anders.nawroth
13 years
New --porefs option, call to translations coming soon, po4a-buid retired
by D. Barbier
Hello,
In a project I am translating into French, I recently discovered that
developers use
po4a-gettextize -o porefs=none ...
to generate PO files without line numbers in references. The
advantage is that POT file is not modified when line numbers change.
Of course, the drawback is that we are losing some information. For
instance, po4aman-display-po could not work on such PO files (and I
really like this tool).
The -o flag above means that porefs is an option of the
Locale::Po4a::Po module. In the last days, I made some commits to also
add a --porefs option to po4a, so that this option is available when
using po4a with a configuration file (instead of calling
po4a-gettextize, po4a-updatepo and po4a-translate).
It works great, I also just added another option --porefs=counter to
not break po4aman-display-po ;)
I will soon update PO files so that you can translate documentation
about these new options. But I want to build PO files with
--porefs=counter. The problem is that I do not know how to do that
with the current build system. So unless someone explains how to do
that with po4a-build, I will very soon revert our build system to
using plain configuration files.
Denis
13 years
parsing asciidoc styles
by Anders Nawroth
Hi!
I found a problem with the parsing of AsciiDoc "styles", or rather,
they are simply not parsed.
Here's an example.
In the original file we have:
[appendix]
Questions & Answers
===================
The po file generated by po4a-gettextize looks like this:
#. type: Plain text
#: target/original/src/qanda/index.asciidoc:4
msgid "[appendix] Questions & Answers"
msgstr "[appendix] Questions & Réponses"
And thus the following get generated when translating:
[appendix] Questions & Réponses
===================
So, "[appendix]" is something called a style in AsciiDoc.
There exists a few predefined styles and you can add your own as well.
The AsciiDoc filters are defined as styles.
I was only going to report this, but after having a look at the newly
refactored (thanks!)
Text.pm I changed my mind and fixed it instead :-)
Here's the essential part of the diff:
- ($line =~
m/^\[(NOTE|TIP|IMPORTANT|WARNING|CAUTION|verse|quote)\]$/)) {
+ ($line =~
m/^\[(NOTE|TIP|IMPORTANT|WARNING|CAUTION|verse|quote|appendix|horizontal|qanda|glossary|bibliography|listing|abstract|partintro|literal|float|normal|comment|example|sidebar|source|music|latex|graphviz|arabic|loweralpha|upperalpha|lowerroman|upperroman)\]$/))
{
I went through the AsciiDoc user guide and added all the styles I
could find in it.
Didn't look into the AsciiDoc sources, though.
A slightly related problem which I didn't fix:
When applying a filter and having attributes/parameters for it, that
line is parsed as plain text.
it should be no-wrap really, I think.
Example:
#. type: Plain text
#: target/original/src/introduction/what-is-a-graphdb.asciidoc:20
msgid "[\"dot\", \"graphdb-GVE.svg\", \"meta\"]"
msgstr "[\"dot\", \"graphdb-GVE.svg\", \"meta\"]"
(We have a bunch of our own AsciiDoc filters, obviously one is named "dot".)
I do think this message should get translated (as there may be
attributes in there that you wish to alter in a translation), but it's
not plain text.
/anders
--
Anders Nawroth [anders(a)neotechnology.com]
Skype: anders.nawroth
13 years
leveloffset attribute in asciidoc
by Anders Nawroth
Hi!
The leveloffset attribute:
#. type: Attribute :leveloffset:
#: target/original/src/introduction/index.asciidoc:20
#: target/original/src/introduction/index.asciidoc:24
#, no-wrap
msgid "2"
msgstr "2"
I think this attribute is a quite clear case of untranslatable string.
The only way this would make any sense would to be to
translate the individual occurrences of the leveloffset attribute.
But even that seems unlikely to be useful ...
And translating all instances with value "2" to some other value makes
no sense to me whatsoever.
See: http://www.methods.co.nz/asciidoc/userguide.html#X90
WDYT?
/anders
--
Anders Nawroth [anders(a)neotechnology.com]
Skype: anders.nawroth
13 years
error parsing document header
by Anders Nawroth
Hi!
I have the following two documents:
The original:
What is a Graph Database?
=========================
The translation:
Qu'est-ce qu'une base de données graphe?
========================================
Running po4a-gettextize on them gives:
po4a gettextization: Structure disparity between original and translated files:
msgid (at target/original/src/dummy.asciidoc:2) is of type 'Title =' while
msgstr (at src/dummy.asciidoc:2) is of type 'Plain text'.
Original text: What is a Graph Database?
Translated text: Qu'est-ce qu'une base de données graphe?
If I change the translation like this:
= Qu'est-ce qu'une base de données graphe? =
then everything is fine, and the following is generated:
#. type: Title =
#: target/original/src/dummy.asciidoc:2
#, fuzzy, no-wrap
msgid "What is a Graph Database?"
msgstr "Qu'est-ce qu'une base de données graphe?"
I won't try fixing this one, the workaround is ok for my use case so far.
And I'm not even sure where in the code to look for this one :-)
/anders
--
Anders Nawroth [anders(a)neotechnology.com]
Skype: anders.nawroth
13 years