Discussion:
Bug#822083: refcard: The refcard layout is screwed up for RTL languages
(too old to reply)
Omer Zak
2016-04-21 06:10:01 UTC
Permalink
Source: refcard
Severity: minor
Tags: upstream patch l10n


The Hebrew and Arabic layouts were fixed by the enclosed patch which is based
upon svn repository version 11118.

1. Explanations of the changes:

debian/rules
LC_ALL=en_US.utf8
Fixes the behavior of 'grep' when it deals with text with non-Latin
characters.
Without this change, 'grep' outputs 'Binary file _____ matches', causing
further operations in the build to fail.

fo.xsl
The layout for RTL languages is fine without writing-mode='rl-tb'.

he.po
All Hebrew translations were enclosed in RLE/PDF to force RTL as their
major direction.
Further fixes were made after proofreading.

ar.po
All Arabic translations were enclosed in RLE/PDF to force RTL as their
major direction.
The file needs to be proofread and more LRE/RLE/PDF characters added at
various strings.

2. Two optional files:

po_processor.py
One-shot script for processing he.po,ar.po and enclosing RTL strings
in RLE/PDF because this directionality is no longer proviced by the
templates subjected to fo.xsl.

The script was written to be idempotent, and you may want to consider
adding it to the build flow, allowing future translators not to manually
enclose new strings in RLE/PDF.

This script requires that python3 and python3-polib be added to the
package's build dependencies.

run_po_processor.sh
Runs the po_processor.py script on ar.po, fa.po (once it exists) and
he.po.
Holger Wansing
2016-04-21 18:40:01 UTC
Permalink
Hi Omer,

Thanks for your work.
Post by Omer Zak
Source: refcard
Severity: minor
Tags: upstream patch l10n
The Hebrew and Arabic layouts were fixed by the enclosed patch which is based
upon svn repository version 11118.
debian/rules
LC_ALL=en_US.utf8
Fixes the behavior of 'grep' when it deals with text with non-Latin
characters.
Without this change, 'grep' outputs 'Binary file _____ matches', causing
further operations in the build to fail.
Are there any possible side effects in setting "LC_ALL=en_US.utf8" ?
Post by Omer Zak
fo.xsl
The layout for RTL languages is fine without writing-mode='rl-tb'.
he.po
All Hebrew translations were enclosed in RLE/PDF to force RTL as their
major direction.
Further fixes were made after proofreading.
ar.po
All Arabic translations were enclosed in RLE/PDF to force RTL as their
major direction.
The file needs to be proofread and more LRE/RLE/PDF characters added at
various strings.
po_processor.py
One-shot script for processing he.po,ar.po and enclosing RTL strings
in RLE/PDF because this directionality is no longer proviced by the
templates subjected to fo.xsl.
The script was written to be idempotent, and you may want to consider
adding it to the build flow, allowing future translators not to manually
enclose new strings in RLE/PDF.
This script requires that python3 and python3-polib be added to the
package's build dependencies.
run_po_processor.sh
Runs the po_processor.py script on ar.po, fa.po (once it exists) and
he.po.
Maybe some comments on how to use that scripts would be useful?
(how to execute, in which situations, ...)



I'm lacking the skills to value this patch, so could please someone comment
on it?


Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Holger Wansing
2016-04-21 19:40:02 UTC
Permalink
Hi,
Post by Holger Wansing
Post by Omer Zak
po_processor.py
run_po_processor.sh
Maybe some comments on how to use that scripts would be useful?
(how to execute, in which situations, ...)
If you apply my patch as is, you do not need to run those scripts.
If you want to start with "clean" ar.po, fa.po and/or he.po files, then
cd refcard
./run_po_processor.sh
and then manually review the output and adjust any LTR strings embedded
in the RTL messages.
Ok.
But when new strings are added to the document, and therefore additional
lines are added to the po files, the po_processor.sh should to be executed
again, right?
That's what I meant with "how to execute, in which situations".
And so it should be well documented in that scripts.


Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Omer Zak
2016-04-21 19:50:02 UTC
Permalink
Post by Holger Wansing
Hi,
Post by Holger Wansing
Post by Omer Zak
po_processor.py
run_po_processor.sh
Maybe some comments on how to use that scripts would be useful?
(how to execute, in which situations, ...)
If you apply my patch as is, you do not need to run those scripts.
If you want to start with "clean" ar.po, fa.po and/or he.po files, then
cd refcard
./run_po_processor.sh
and then manually review the output and adjust any LTR strings embedded
in the RTL messages.
Ok.
But when new strings are added to the document, and therefore additional
lines are added to the po files, the po_processor.sh should to be executed
again, right?
That's what I meant with "how to execute, in which situations".
And so it should be well documented in that scripts.
If the translators enclose the new RTL strings by RLE/PDF, then it is
not necessary to run the scripts. This is why I said that they are
optional.
Holger Wansing
2016-04-23 18:40:02 UTC
Permalink
Hi,
Post by Omer Zak
Post by Holger Wansing
Ok.
But when new strings are added to the document, and therefore additional
lines are added to the po files, the po_processor.sh should to be executed
again, right?
That's what I meant with "how to execute, in which situations".
And so it should be well documented in that scripts.
If the translators enclose the new RTL strings by RLE/PDF, then it is
not necessary to run the scripts. This is why I said that they are
optional.
But it does not harm, right?

The point is: if the translator does not enclose the new RTL strings by
RLE/PDF, that can be done by the package maintainer via that script
instead - if he know about that, and how to use it.


Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Omer Zak
2016-04-23 19:10:02 UTC
Permalink
Post by Holger Wansing
Hi,
Post by Omer Zak
Post by Holger Wansing
Ok.
But when new strings are added to the document, and therefore additional
lines are added to the po files, the po_processor.sh should to be executed
again, right?
That's what I meant with "how to execute, in which situations".
And so it should be well documented in that scripts.
If the translators enclose the new RTL strings by RLE/PDF, then it is
not necessary to run the scripts. This is why I said that they are
optional.
But it does not harm, right?
Right.
Post by Holger Wansing
The point is: if the translator does not enclose the new RTL strings by
RLE/PDF, that can be done by the package maintainer via that script
instead - if he know about that, and how to use it.
The instructions are in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822083#25

and they are simply:
cd refcard
./run_po_processor.sh
Omer Zak
2016-04-21 20:10:02 UTC
Permalink
Post by Holger Wansing
Are there any possible side effects in setting "LC_ALL=en_US.utf8" ?
Nothing that I am aware of.
Post by Holger Wansing
Post by Omer Zak
po_processor.py
run_po_processor.sh
Maybe some comments on how to use that scripts would be useful?
(how to execute, in which situations, ...)
If you apply my patch as is, you do not need to run those scripts.
If you want to start with "clean" ar.po, fa.po and/or he.po files, then
just:
cd refcard
./run_po_processor.sh

and then manually review the output and adjust any LTR strings embedded
in the RTL messages.
Holger Wansing
2016-05-27 19:40:01 UTC
Permalink
Hi,
Post by Holger Wansing
Post by Omer Zak
Source: refcard
Severity: minor
Tags: upstream patch l10n
The Hebrew and Arabic layouts were fixed by the enclosed patch which is based
upon svn repository version 11118.
debian/rules
LC_ALL=en_US.utf8
Fixes the behavior of 'grep' when it deals with text with non-Latin
characters.
Without this change, 'grep' outputs 'Binary file _____ matches', causing
further operations in the build to fail.
Are there any possible side effects in setting "LC_ALL=en_US.utf8" ?
Post by Omer Zak
fo.xsl
The layout for RTL languages is fine without writing-mode='rl-tb'.
he.po
All Hebrew translations were enclosed in RLE/PDF to force RTL as their
major direction.
Further fixes were made after proofreading.
ar.po
All Arabic translations were enclosed in RLE/PDF to force RTL as their
major direction.
The file needs to be proofread and more LRE/RLE/PDF characters added at
various strings.
po_processor.py
One-shot script for processing he.po,ar.po and enclosing RTL strings
in RLE/PDF because this directionality is no longer proviced by the
templates subjected to fo.xsl.
The script was written to be idempotent, and you may want to consider
adding it to the build flow, allowing future translators not to manually
enclose new strings in RLE/PDF.
This script requires that python3 and python3-polib be added to the
package's build dependencies.
run_po_processor.sh
Runs the po_processor.py script on ar.po, fa.po (once it exists) and
he.po.
Maybe some comments on how to use that scripts would be useful?
(how to execute, in which situations, ...)
I'm lacking the skills to value this patch, so could please someone comment
on it?
Are there any objections against me committing that parts of the patch,
which are related to Hebrew?
Since I have no proofreader for Arabic until now, I feel somewhat uncomfortable
with applying changes to Arabic ATM.


Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Holger Wansing
2016-05-29 19:30:01 UTC
Permalink
Hi,
Post by Holger Wansing
Post by Holger Wansing
Post by Omer Zak
debian/rules
LC_ALL=en_US.utf8
Fixes the behavior of 'grep' when it deals with text with non-Latin
characters.
Without this change, 'grep' outputs 'Binary file _____ matches', causing
further operations in the build to fail.
[...]
Post by Holger Wansing
Post by Holger Wansing
I'm lacking the skills to value this patch, so could please someone comment
on it?
Are there any objections against me committing that parts of the patch,
which are related to Hebrew?
Since I have no proofreader for Arabic until now, I feel somewhat uncomfortable
with applying changes to Arabic ATM.
Holger
I should have mentioned explicitly, that Omer proposed to change the global
build variables in debian/rules, so that might affect all languages!

Are there any known side effects or objections on adding
LC_ALL=en_US.utf8
to the used environment variables for building refcard?


I could not see any difference while testing the proposed chagings though.



Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Holger Wansing
2016-06-14 21:00:01 UTC
Permalink
Hi,
Hi,
Post by Holger Wansing
Post by Holger Wansing
Post by Omer Zak
debian/rules
LC_ALL=en_US.utf8
Fixes the behavior of 'grep' when it deals with text with non-Latin
characters.
Without this change, 'grep' outputs 'Binary file _____ matches', causing
further operations in the build to fail.
[...]
Post by Holger Wansing
Post by Holger Wansing
I'm lacking the skills to value this patch, so could please someone comment
on it?
Are there any objections against me committing that parts of the patch,
which are related to Hebrew?
Since I have no proofreader for Arabic until now, I feel somewhat uncomfortable
with applying changes to Arabic ATM.
I have committed Omer's patch, except from the changings on ar.po, as mentioned
above.


Holger
--
============================================================
Created with Sylpheed 3.5.0 under
D E B I A N L I N U X 8 . 0 " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/
============================================================
Holger Wansing
2019-01-17 18:40:01 UTC
Permalink
Control: tags -1 + wontfix
Post by Omer Zak
Source: refcard
Severity: minor
Tags: upstream patch l10n
The Hebrew and Arabic layouts were fixed by the enclosed patch which is based
upon svn repository version 11118.
Since ar and he versions of the refcard are no longer being built ATM (sadly :-(( )
I'm tagging this bug as wontfix.

If we manage to get RTL languages enabled again, this bug can be re-considered.


Holger
--
Holger Wansing <***@mailbox.org>
PGP-Finterprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Debian Bug Tracking System
2019-01-17 18:40:01 UTC
Permalink
Post by Holger Wansing
tags -1 + wontfix
Bug #822083 [src:refcard] refcard: The refcard layout is screwed up for RTL languages
Added tag(s) wontfix.
--
822083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822083
Debian Bug Tracking System
Contact ***@bugs.debian.org with problems
Loading...