6:23 a.m.
Hi,
On Wed, 23 Mar 2005, Martin Quinson wrote:
[...]
From what I can see, the entities are rewritten before the content
is
extracted to po files. This is bad because it will unnecessary fuzzy the
strings when the entity content change. In po4a/sgml, entities are
translated separately, and then the entities are preserved into msgids. I'm
not sure about po4a/xml.
Entities are still not handled in the xml module :(
The most interesting point is that they provide an heuristic for
automatic
tags classification. Maybe from dtd, I only glanced the code. But at the
same time, they provide specific "modes" for the dtd they use (docbook and
gnomesummary). If it works, it's exactly what I'm dreaming of since years.
I think that it could be interesting to :
- see whether we can reuse their automatic classification heuristic
I'm not used with python, so I'll leave it to other skilled programmers ;)
- build a gnomesummary module from their one (it looks really easy
to do)
If it should only contain the translateable tags, it's so easy to do.
(attaching it to my TODO list...)
- contact the authors to see whether they would accept to merge our
efforts
since it's also python based, we may well get the same result than with
the translate project (both parts willing to merge, none willing to
switch the programming language, and no change as result), but it worth
trying...
Your advice?
My vision is that all these efforts have to merge, and I propose the following
long term steps:
- First, we (all the involved projects) should define a common interface
(extending the TransTractor one, for example) that would be able to
handle all the posible file formats (more than one translation on the
same file, etc.)
- Second, we should implement the new kernel app that is able to handle
everything defined in the first step using plugins.
- Third, each project could build his own file format plugins in their
preferred language.
PS: I dream of Perl6, which will make possible the code sharing
between
perl, python and even java ;)
I support C/C++ for the kernel app, which has interfaces to lots of other
languages, and it could also bring us some more performance.
Maybe all this is like an utopia, but I think it's the way to go. If we decide
to follow one of these roads we should tell the other projects.
The main spanish translators group has proposed a small encounter of the
translation efforts (translators themselves and tools' developers) for next
summer. I think it could be a nice event to talk about all these issues. I'll
be forwarding all the information I get about it.
Regards,
Jordi Vilalta
4:44 a.m.
New subject: [Po4a-devel]Merging po4a-like efforts?
On Sun, Apr 17, 2005 at 01:23:43PM +0200, Jordi Vilalta wrote:
Hi,
My vision is that all these efforts have to merge, and I propose the
following long term steps:
- First, we (all the involved projects) should define a common interface
(extending the TransTractor one, for example) that would be able to
handle all the posible file formats (more than one translation on the
same file, etc.)
- Second, we should implement the new kernel app that is able to handle
everything defined in the first step using plugins.
- Third, each project could build his own file format plugins in their
preferred language.
> PS: I dream of Perl6, which will make possible the code sharing between
> perl, python and even java ;)
I support C/C++ for the kernel app, which has interfaces to lots of other
languages, and it could also bring us some more performance.
I never thought about this, but it is a lightning idea. One of the big
difference between now and the days I begun hacking on po4a is that now,
gettext exports a library we could link against. I know it exists, but I
never looked at this very closely.
I tried several times to think about a merge between po4a and gettext, but
the modules using so much perl features (regexps, eval) I though it was
impossible. I never thought about implementing the kernel (Po.pm and
TransTractor.pm) in C and leaving the modules in Perl.
Again, that's a very good idea.
Maybe all this is like an utopia, but I think it's the way to go.
If we
decide to follow one of these roads we should tell the other projects.
Well. I'm quite sure some of them are on this list ;) And I'm not sure we
should announce it too much before it gets implemented. I mean that I won't
have much time for this before months, and I hate announcing what I can't do ;)
The main spanish translators group has proposed a small encounter of
the
translation efforts (translators themselves and tools' developers) for next
summer. I think it could be a nice event to talk about all these issues.
I'll be forwarding all the information I get about it.
Hey, a little trip to espan~a this summer would be good ;)
Mt.
4 p.m.
New subject: [Po4a-devel]Merging po4a-like efforts?
On Wed, 27 Apr 2005, Martin Quinson wrote:
On Sun, Apr 17, 2005 at 01:23:43PM +0200, Jordi Vilalta wrote:
> Maybe all this is like an utopia, but I think it's the way to go. If we
> decide to follow one of these roads we should tell the other projects.
Well. I'm quite sure some of them are on this list ;) And I'm not sure we
should announce it too much before it gets implemented. I mean that I won't
have much time for this before months, and I hate announcing what I can't do ;)
I meant to ask for help to other groups:
> - First, we (all the involved projects) should define a common
interface
> (extending the TransTractor one, for example) that would be able to
> handle all the posible file formats (more than one translation on the
> same file, etc.)
I think we should talk to other projects to see their point of view, and
to be able to define a generic enough solution. Else we would fall into a
limited solution that would leave us nearly where we are now (each project
dealing with their own solution).
And maybe it would be interesting to create a new common project to
concentrate all these projects' people doing the kernel, for example.
Regards,
Jordi Vilalta
5:18 p.m.
New subject: [Po4a-devel]Merging po4a-like efforts?
On Wed, Apr 27, 2005 at 11:00:44PM +0200, Jordi Vilalta wrote:
On Wed, 27 Apr 2005, Martin Quinson wrote:
>On Sun, Apr 17, 2005 at 01:23:43PM +0200, Jordi Vilalta wrote:
>>Maybe all this is like an utopia, but I think it's the way to go. If we
>>decide to follow one of these roads we should tell the other projects.
>
>Well. I'm quite sure some of them are on this list ;) And I'm not sure we
>should announce it too much before it gets implemented. I mean that I won't
>have much time for this before months, and I hate announcing what I can't
>do ;)
I meant to ask for help to other groups:
sure, but maybe preparing a preliminary specification could help, I think.
As you say, we need to find a way to deal with multi-translation document in
transtractor and it then can be considered as a proof of concept
implementation of the kernel. At least, I think so.
>>- First, we (all the involved projects) should define a
common interface
>> (extending the TransTractor one, for example) that would be able to
>> handle all the posible file formats (more than one translation on the
>> same file, etc.)
I think we should talk to other projects to see their point of view, and
to be able to define a generic enough solution. Else we would fall into a
limited solution that would leave us nearly where we are now (each project
dealing with their own solution).
In my mind, the main show stopper to the merge for now is that everyone uses
python beside us, which prevent us from stealing as much code as I would
like to. If we go for a C interface, we could share more easily. po4a could
become a C/perl/python stuff, if we're crazy enough to go that way.
And maybe it would be interesting to create a new common project to
concentrate all these projects' people doing the kernel, for example.
If you feel like speaking about this idea to the other groups, it'd be great
;)
Thanks for your time,
Mt.
6939
days inactive
6949
days old
3 comments
2 participants
participants (2)
-
Jordi Vilalta -
Martin Quinson