kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi again,

Am 20.05.18 um 04:17 schrieb Carsten Schoenert:
...
>>>  898 \item{} キーボード（ファンクションキー \texttt{F1}, \texttt{F2}, \texttt{F3}, \texttt{F4}, \texttt{Shift}, \texttt{Delete}, \texttt{+}, \texttt{-{}}, \texttt{Page
>>>  899   Up}, \texttt{Page Down} 及び \texttt{スペース バー\`{}）。\`{}エスケープ} キーは、一般的に進行中の操作を取り消します。
>>>  900                                                    ^^     ^^
>>
>> This looks indeed not correct as the two curly brackets in line 899 are
>> empty and shouldn't be here.
> 
> As this issue will unfortunately stay for a while I will drop the origin
> of this problem from the Japanese po file temporary to get a new package
> upload into Debian prepared. I really don't like this but without this I
> will miss the possibility to get 5.0.0RC2 into Debian testing.
> 
> If there will be a KiCad 5 RC2 in the next days I will happily use this
> tagged version, otherwise I'll take a current snapshot for getting a new
> version into Debian unstable/testing.

thanks to Norbert Preining, the current maintainer of the texlive
packages within Debian, we figured out why the build is currently
failing with recent texlive versions in Debian unstable and sid.

The real problem isn't texlive in our opinion after a few hours of
debugging, texlive is now just a bit more picky about some input strings
and I see the broken build later. We first was thinking about xcjk or
xecjk as the root of the issues. By using some simple tex examples we
couldn't reproduce the issue again so we went to the toolchain that is
working in kicad-doc.

So we came to dblatex which is running a2x, xsltproc ans asciidoc and
checked the tools from the end to the beginning, and, well ... we
unfortunately need to go back the the complete road to the beginning at
asciidoc which is generating the xml file which is used later by most of
the tools.

And it points finally out that asciidoc is the problem!

asciidoc is a Python2 script which doesn't know anything about UTF8
string and by this the recompile is simply going wrong for Japanese in
pcbnew.adoc.
This might be fixed by improved the regexp, I've no idea if this
possible as I have just a poor understanding about this.

So we made just a small change to workaround the build issue within the
Japanese po file and Norbert mentioned this is currently the best way to
get it working. He's living for many years in Japan and I trust his
knowledge.

So the change is trivial, we just added space characters and the build
is succesful.

> $ git diff
> diff --git a/src/pcbnew/po/ja.po b/src/pcbnew/po/ja.po
> index 60cc711f..b61d9a7b 100644
> --- a/src/pcbnew/po/ja.po
> +++ b/src/pcbnew/po/ja.po
> @@ -5745,7 +5745,7 @@ msgid ""
>  "an operation in progress."
>  msgstr ""
>  "キーボード（ファンクションキー `F1`, `F2`, `F3`, `F4`, `Shift`, `Delete`, `"
> -"+`, `-`, `Page Up`, `Page Down` 及び `スペース バー`）。`エスケープ` キーは、"
> +"+`, `-`, `Page Up`, `Page Down` 及び `スペース バー` ）。 `エスケープ` キーは、"
>  "一般的に進行中の操作を取り消します。"
>  
>  #. type: Plain text

The reason is the recompile regexp within asciidoc is a bit to stupid to
detect the backticks signs are needed in the original string and is
breaking the original string into multiple parts which fails later due
missing controlling escaping character.

-- 
Regards
Carsten Schoenert