[PD] more fun with translations

[Jonathan Wilkes]

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: "pd-list at iem.at list" <pd-list at 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 at.or.at>
>>>  To: Jonathan Wilkes <jancsika at yahoo.com>
>>>  Cc: "pd-list at iem.at list" <pd-list at 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 at.or.at>
>>>>>   To: Jonathan Wilkes <jancsika at yahoo.com>
>>>>>   Cc: "pd-list at iem.at list" <pd-list at 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:

http://gridflow.ca/help/

> 
> 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
>