Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Ludovic Courtès via RT 
"Ineiev via RT"  skribis:

> On 01/10/2014 03:12 AM, Ludovic Courtès via RT wrote:
>  >>
>  >> (0) when a new (or corrected) translation is committed to www, www
>  >> translators send updates to TP, and they merge it to their PO files;
>  >>
>  >> (1) when a new translation is submitted to TP, the translators send
>  >> a copy to the respective www.gnu.org translation team (or
>  >> web-translat...@gnu.org if that team doesn't maintain blurb
>  >> translation for some reason); of course, TP translators should know
>  >> what strings are blurbs.
>  >
>  > Sounds good.
>  >
>  > What would it take exactly to inform the TP folks of the process?
>
> Discuss with coordina...@translationproject.org, I think; they may add
> their own adjustments to the procedure before actually announcing it
> to the translators.

OK, will do (once the remaining issue is solved.)

>  >> However, there is a technical problem: www translations are in HTML,
>  >> while guix uses plain text. it's easy to transform plain text to HTML;
>  >> the reverse conversion seems missing.
>  >
>  > Seems to me that the only difference in the translated strings is that
>  > the www ones have something like this at the end:
>  >
>  >   (doc)
>  >
>  > Would it be possible somehow to remote that link from the translatable
>  > strings?
>
> But they are translatable; what may make sense is separating them
> to their own msgids (also, "This package is looking for a maintainer.").
>
> GNUN has a means to do it when the strings can't come, say, in separate
> paragraphs, , like on the home page [0],
> so this could be implemented like in the attachment.

Excellent.

> Then, there are also s (which may "translate" into something
> different, like  or ) and a few other substitutions [1].
> I wonder whether it would be easier if guix used HTML in PO files and
> converted it to plain text when needed; this way, no exact reverse
> conversion would be necessary.

That would be possible.  However, we synchronize the descriptions in our
source files directly with pkgblurbs.txt, which is *not* HTML.

So, should pkgblurbs.txt be changed to use HTML markup, should we keep
using it but implement the same markup-inference trick, or should we use
another source, or...?

It seems to me that the ideal would be to have (HTML) markup in the
authoritative source (pkgblurbs.txt).  Then users could choose whether
to keep/convert/discard that markup.  I believe it’s more flexible and
robust than trying to infer markup from plain text like gm-generate.pl
currently does.

WDYT?

Thanks for your help!

Ludo’.

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Ludovic Courtès 
"Ineiev via RT"  skribis:

> On 01/10/2014 03:12 AM, Ludovic Courtès via RT wrote:
>  >>
>  >> (0) when a new (or corrected) translation is committed to www, www
>  >> translators send updates to TP, and they merge it to their PO files;
>  >>
>  >> (1) when a new translation is submitted to TP, the translators send
>  >> a copy to the respective www.gnu.org translation team (or
>  >> web-translat...@gnu.org if that team doesn't maintain blurb
>  >> translation for some reason); of course, TP translators should know
>  >> what strings are blurbs.
>  >
>  > Sounds good.
>  >
>  > What would it take exactly to inform the TP folks of the process?
>
> Discuss with coordina...@translationproject.org, I think; they may add
> their own adjustments to the procedure before actually announcing it
> to the translators.

OK, will do (once the remaining issue is solved.)

>  >> However, there is a technical problem: www translations are in HTML,
>  >> while guix uses plain text. it's easy to transform plain text to HTML;
>  >> the reverse conversion seems missing.
>  >
>  > Seems to me that the only difference in the translated strings is that
>  > the www ones have something like this at the end:
>  >
>  >   (doc)
>  >
>  > Would it be possible somehow to remote that link from the translatable
>  > strings?
>
> But they are translatable; what may make sense is separating them
> to their own msgids (also, "This package is looking for a maintainer.").
>
> GNUN has a means to do it when the strings can't come, say, in separate
> paragraphs, , like on the home page [0],
> so this could be implemented like in the attachment.

Excellent.

> Then, there are also s (which may "translate" into something
> different, like  or ) and a few other substitutions [1].
> I wonder whether it would be easier if guix used HTML in PO files and
> converted it to plain text when needed; this way, no exact reverse
> conversion would be necessary.

That would be possible.  However, we synchronize the descriptions in our
source files directly with pkgblurbs.txt, which is *not* HTML.

So, should pkgblurbs.txt be changed to use HTML markup, should we keep
using it but implement the same markup-inference trick, or should we use
another source, or...?

It seems to me that the ideal would be to have (HTML) markup in the
authoritative source (pkgblurbs.txt).  Then users could choose whether
to keep/convert/discard that markup.  I believe it’s more flexible and
robust than trying to infer markup from plain text like gm-generate.pl
currently does.

WDYT?

Thanks for your help!

Ludo’.

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread John Darrington via RT 
On Fri, Jan 10, 2014 at 12:44:25AM -0500, Ineiev via RT wrote:
 
 Then, there are also s (which may "translate" into something
 different, like  or ) and a few other substitutions [1].
 I wonder whether it would be easier if guix used HTML in PO files and
 converted it to plain text when needed; this way, no exact reverse
 conversion would be necessary.

It's become a kindof de facto standard, that html text in  should
not ever be translated.  This is a useful convention to follow so that automatic
html translation services can recognise texts which should be left untranslated.

I don't see any advantages for Gnu not to follow this convention.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread John Darrington 
On Fri, Jan 10, 2014 at 12:44:25AM -0500, Ineiev via RT wrote:
 
 Then, there are also s (which may "translate" into something
 different, like  or ) and a few other substitutions [1].
 I wonder whether it would be easier if guix used HTML in PO files and
 converted it to plain text when needed; this way, no exact reverse
 conversion would be necessary.

It's become a kindof de facto standard, that html text in  should
not ever be translated.  This is a useful convention to follow so that automatic
html translation services can recognise texts which should be left untranslated.

I don't see any advantages for Gnu not to follow this convention.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Re: Signed archive export/import

2014-01-10 Thread Ludovic Courtès 
l...@gnu.org (Ludovic Courtès) skribis:

> l...@gnu.org (Ludovic Courtès) skribis:
>
>> The good news is that, with a bit of work in (guix nar),
>> ‘substitute-binary’ will be able to use that mechanism too.  So we can
>> change Hydra to always sign its archives (simple), and
>> ‘substitute-binary’ to always check signatures and check the signer
>> against the ACL.  The users can choose whether or not to add
>> hydra.gnu.org’s public key to their ACL.
>
> It turns out that changing Hydra to always sign is not as simple as I
> initially thought, because it doesn’t export archives via the
> ‘export-paths’ RPC (the one that knows how to sign them.)
>
> So we’re back to discussing another approach with the (apparently
> unmotivated) Hydra folks, probably adding a ‘Signature’ field to the
> .narinfo files (see
>  and
> .)

Good news: Eelco Dolstra (of Nix) implemented what he had in mind in
Hydra and Nix’s substituter (thanks!):

  https://github.com/NixOS/nix/commit/0fdf4da0e979f992db75cc17376e455ddc5a96d8
  https://github.com/NixOS/hydra/commit/a598fe7e817e116cdf4d3202458d138202e869f1

So what we need to do now is to adjust substitute-binary.scm to handle
these signatures, and to make sure Hydra can use ‘guix authenticate’
instead of ‘openssl’.

I’ll look into it when I’m done with offload support, but I’m happy to
discuss it further if someone else wants to give it a go!

Ludo’.

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Ineiev via RT 
On 01/10/2014 01:20 PM, John Darrington via RT wrote:
> On Fri, Jan 10, 2014 at 12:44:25AM -0500, Ineiev via RT wrote:
>  
>  Then, there are also s (which may "translate" into something
>  different, like  or ) and a few other substitutions [1].
>  I wonder whether it would be easier if guix used HTML in PO files and
>  converted it to plain text when needed; this way, no exact reverse
>  conversion would be necessary.
> 
> It's become a kindof de facto standard, that html text in  should
> not ever be translated.  This is a useful convention to follow so that 
> automatic
> html translation services can recognise texts which should be left 
> untranslated.
> 
> I don't see any advantages for Gnu not to follow this convention.

I was not clear enough, what I meant was: the original text says,
--
foo uses "--bar" to baz.
--

gm-generate.pl converts it to
--
foo uses --bar to baz.
--

Now, some translator may replace the  tag with :
--
когда foo видит --bar, она бацает.
--

This makes the conversion of the translation (from HTML to plain text
and back) non-trivial.

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Ineiev via RT 
On 01/10/2014 01:17 PM, Ludovic Courtès via RT wrote:
> It seems to me that the ideal would be to have (HTML) markup in the
> authoritative source (pkgblurbs.txt).  Then users could choose whether
> to keep/convert/discard that markup.  I believe it’s more flexible and
> robust than trying to infer markup from plain text like gm-generate.pl
> currently does.
> 
> WDYT?

I think it may depend on the usage scenarios.

Karl?

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Karl Berry 
I thought you guys didn't want these hypothetical TP translators to see
HTML.  If you do, fine, we can make the original be HTML, at least as
far as the internal text goes, which is the only concern here afaik.

Brandon and I wrote the blurbs in plain text simply because it seemed
natural; everything else we do starts with plain text, and there seemed
no reason to do otherwise.  Then I wrote gm-generate.pl to add HTML
boilerplate junk and convert the obvious things into HTML as needed
because that's how the text was needed on the web site.

It all seems far more trivial to me than this thread would imply.  

Whatever,
k

Re: [gnu.org #881181] Re: [gnu.org #881518] Re: Package synopses and blurbs translation

2014-01-10 Thread Karl Berry via RT 
I thought you guys didn't want these hypothetical TP translators to see
HTML.  If you do, fine, we can make the original be HTML, at least as
far as the internal text goes, which is the only concern here afaik.

Brandon and I wrote the blurbs in plain text simply because it seemed
natural; everything else we do starts with plain text, and there seemed
no reason to do otherwise.  Then I wrote gm-generate.pl to add HTML
boilerplate junk and convert the obvious things into HTML as needed
because that's how the text was needed on the web site.

It all seems far more trivial to me than this thread would imply.  

Whatever,
k