[PD] more fun with translations

[Pierre-Olivier Boulant]

On 28/12/2012 23:42, Hans-Christoph Steiner wrote:
> On 12/28/2012 05:21 PM, Pierre-Olivier Boulant wrote:
>>
>> On 28/12/2012 23:00, Hans-Christoph Steiner wrote:
>>> 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.
>>>
>>>>> Making this part of the normal Pd editor would be harder.  There would
>>>>> need to
>>>>> be a way for a patch to be marked with a locale, something like:
>>>>>
>>>>> #X declare -locale fr_CA
>>>>>
>>>>> Then that would make all 'text' items assumed to be fr_CA.  Then there
>>>>> would
>>>>> need to be a way to change the visible locale.  Seems tricky to do it
>>>>> right in
>>>>> the UI.  That's why a compiled technique is appealing.
>>>>>
>>>>> pob just suggested another route, which is sticking the locale in the file
>>>>> name, i.e bang-help.fr.pd
>>>> Hm, that is probably (and unfortunately) necessary because Pd patches cannot
>>>> automatically adjust themselves vertically to make room if more lines of
>>>> text are
>>>> needed.  So if you have a one-line comment in English that turns into two
>>>> lines in
>>>> French, your system of text_po will end up with overlapping text and thus
>>>> illegible
>>>> patches.
>>>>
>>>> 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.  At that point you have a good 'tidy up'
>>> algorithm.  So I think its possible to adjust the layout so it fits well
>>> enough for all langauges, then just save the file like that.
>>>
>>> .hc
>> Are you planning an exception for Arabic and Hebrew? :)
>> I suppose that Japanese and Chinese on computers is written in the Latin
>> order, left to right and then top to bottom.
>> http://www.omniglot.com/writing/direction.htm
> What exception would be needed for Right-to-Left languages?  They are still
> blocks of text with roughly the same line breaking rules, with the biggest
> difference in layout being that its right-justified instead of left justified.
>
> .hc

Some help patches are on two columns, [trigger]'s one for instance.

pob