----- Original Message ----- > From: Hans-Christoph Steiner <[email protected]> > To: Jonathan Wilkes <[email protected]> > Cc: "[email protected] list" <[email protected]> > 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 <[email protected]> >>> To: Jonathan Wilkes <[email protected]> >>> Cc: "[email protected] list" <[email protected]> >>> 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 <[email protected]> >>>>> To: Jonathan Wilkes <[email protected]> >>>>> Cc: "[email protected] list" <[email protected]> >>>>> 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 > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
