[Padre-dev] localizing plugin documentation

[breno]

Can anyone point to such tool so we can update the
http://padre.perlide.org/wiki/TranslationIntro wiki? As of now I only
know of POEdit and, although it does a nice job for small texts, it
says "this string changed", and not "this string changed *here*". So
using it to track a small change in a long paragraph (or an entire set
of paragraphs, as we're talking about documentation) can become very
frustrating, as we'll not know where it changed unless we look really
hard.

A translation tool that showed a diff between previous and current
originals with the translation box for you to update right next to it
would make this go away, I suppose.

Cheers,

garu

2009/4/30 Adam Kennedy <adamkennedybackup at gmail.com>:
> I think the main point of gettext (and correct me if I'm wrong here,
> since I don't do any translating) is that robust tools already exist
> that track and manage change, and (I assume) do diff-like things for
> you in the translation tools?
>
> And we get all this tooling for free if we use gettext.
>
> Adam K
>
> 2009/4/30 breno <breno at rio.pm.org>:
>> 2009/4/29 Cezary Morga <cm at therek.net>:
>>> Dnia środa, 29 kwietnia 2009, Jerome Quelin napisał:
>>>> On 09/04/29 12:26 +1000, Adam Kennedy wrote:
>>>> > I can't think of any Perl/CPAN project that has ever tried to do i18n
>>>> > at this level of depth, so I'm not too worried about us just trying
>>>> > something, and having some false starts.
>>>>
>>>> sure
>>>>
>>>> > That said, might be interesting to ask around and see if anyone else
>>>> > has managed to implement anything similar.
>>>> >
>>>> > I wonder if we could just get away with something like
>>>> > Padre/Plugin/Foo.pm
>>>> > Padre/Plugin/Foo/PT.pod
>>>> >
>>
>> I *think* POD2::Base does almost that. But I like yours better, as it
>> seems to scale nicer for too many pods.
>>
>>>> > That said, would doing things via POD make life unusually difficult
>>>> > for the translators?
>>>
>>> I've used to work on translating FreeBSD documentation. It's generated from
>>> SGML source so some basic markup here and there is not much of a problem for
>>> translators and POD is basic markup.
>>>
>>>> and let's not even mention the problem of "has the pod changed since
>>>> last time, and where?"
>>>
>>> That's a bigger issue, though.
>>
>> Maybe I'm being over simplistic here, but once (if) the POD is under
>> revision control in the plugin, we could diff the originals to see
>> where they changed, and thus know where the translation should be
>> updated, right? It could be automatized - and it appears such a tool
>> could be a great benefit for translators elsewhere, such as on the
>> FBSD project, as therek pointed out. But then again I'm new to this
>> whole translation business and might not be getting the full picture.
>>
>> The idea of using gettext makes it a lot easier to do small text, but
>> I agree with Alias on two accounts:
>>
>> - It's plugin documentation, so expected fields (specially
>> "description") could become large enough for gettext to be not so much
>> better than plain POD translation.
>>
>>  - It's plugin documentation, so it can grow a lot and, if it's loaded
>> to memory, people who just want to use the plugin will have to cope
>> with the memory issues.
>>
>> Whatever direction we take, I think we should try to make the plugin
>> documentation translation consistent with whatever way Padre is
>> deploying its own help/documentation content.
>>
>>
>> Cheers,
>>
>> garu
>> _______________________________________________
>> Padre-dev mailing list
>> Padre-dev at perlide.org
>> http://mail.perlide.org/mailman/listinfo/padre-dev
>>
> _______________________________________________
> Padre-dev mailing list
> Padre-dev at perlide.org
> http://mail.perlide.org/mailman/listinfo/padre-dev
>