----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at list" pd-list@iem.at Sent: Friday, December 28, 2012 5:47 PM Subject: Re: [PD] more fun with translations
On 12/28/2012 05:43 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at list" pd-list@iem.at Sent: Friday, December 28, 2012 5:00 PM Subject: Re: [PD] more fun with translations
On 12/28/2012 04:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at list" pd-list@iem.at Sent: Friday, December 28, 2012 2:39 PM Subject: Re: [PD] more fun with translations
[...]
No, the idea would be there would be an editor for them, so
that the
strings
can be extracted and put up on transifex, and then downloaded
and
inserted
into a patch file. That would be the method for bulk
translation.
Doesn't Transifex make Pd-Extended dependent and to some
extent locked
in
to a commercial web service?
Transifex is all free software, so someone could run their own
transifex
instance if they wanted to. Transifex is based on the standard GNU
gettext
tools, so its easy to stop using it at anytime, and just use the normal
.po
translation tools like poedit. It is a commercial service, but I have
no
problem with commerce. Since it is not proprietary service, I see it
as a
great free software tool to support our free software work.
Oh ok, I seem to have misunderstood what it was.
BTW-- matju's GF helpsystem _does_ adjust vertical space as
needed. :)
I think that automated text layout won't work well unless the
layout engine
can also move the patch stuff around.
I don't understand what this means. The GF abstractions get their x,y
coordinates
adjusted as needed to provide enough vertical space for everything.
-Jonathan
I meant that either the help patch would need to be laid out so that the auto-layout would not make the text overlap the example patch part, or the auto-layout would have to be aware of the patch part.
None of the GF help patches have collisions between the example patch and text. I'm not sure if it's automatic or if you have to click drag the first text-heading below the patch, but either way it behaves and there are no collisions in any of matju's docs that I've seen:
Another solution would be to have a text/comment field that saves carriage returns and paragraph breaks. Then a whole column of text could be in a single object, and then there would just need to be room at the bottom to accomodate different lengths of texts, depending on the language.
You can't criticize GF automated help patches for requiring the user to do a single click-drag to pull the first heading below the example patch (if they indeed do require that-- I'll have to check), and then favor a system that not only requires the author to click drag to increase patch height but also guess how much extra room they must leave for other systems they don't use where the vertical space between lines may be slightly larger than the system they are using.
AFAICT, GF help patches measure the actual space used by the comments so that even if you save a patch on system X, when someone opens it on system Y it will shift comments down if they need extra space in order to avoid overlapping.
-Jonathan
.hc