[Po4a-devel] Changing programming languages

[Martin Quinson]

Hello,

On Fri, Feb 09, 2018 at 10:04:58AM +0100, Brian Exelbierd wrote:
> 
> On Thu, Feb 8, 2018, at 10:06 PM, Martin Quinson wrote:
> 
> > If you know how to program in python, you could try to come up with a
> > prototype of po4a reimplementation. I'm getting the feeling that Perl
> > is not the right choice anymore. But the prototype may be difficult
> > because we use the regular expressions so much. Scala would probably
> > be easier, but I would not say that Scala is a much wiser choice here.
> > I dunno what Scala will become in the next decade (which may be the
> > last decade for Perl).
> 
> we could use perl6 :P
> 
> Seriously, I am not sure that changing languages buys us a lot if we
> don't think through the architecture first.  One question I would like
> to have to explore is "How many of our formats now have canonical or
> 'really good' processors that we could leverage instead of writing new
> parsers?"

I must confess that I'm rather happy with the current architecture
[1]. I still think that it nicely allows to split the generic concerns
(dealing with the po file, deciding which files to update, etc) from
the format-specific concerns. We could go a bit further over that
line, and deal with includes in a generic manner.

  [1] https://po4a.org/man/man3/Locale::Po4a::TransTractor.3pm.php

We may want to change the current code organization of several
independent binaries (po4a-gettextize po4a-normalize po4a-translate
po4a-updatepo) that are called from po4a. Historically, po4a was
created as a layer over the other ones, and retrospectively, I think
that a git-like organisation (with subcommands that cannot be accessed
directly) would be more adapted. Likewise, po4a-build could be merged
back into ... something.

But I still like the idea of TransTractors in charge of parsing the
structure to both separate the translatable original content that goes
to the po file and also inject the translated content in place. It
prevents from using existing unmodified parsers (that are never meant
to offer that service -- (2)), but this idea makes it really simple to
add new formats to the picture. This design still seems clean and lean
to me after all these years. In the other projects I'v seen, each
formats are handled with a completely specific toolchain with almost
no shared concerns.

 (2) If you have *one* parser (regardless of its language) allowing to
     separate translatable content from the structure, and that could
     be used as a library to share generic concerns over several
     parsers, I'd be really really interested. I don't know any.

The thing that I miss the most in the current TransTractor API is that
you cannot loop over the languages. That's what you would need to deal
with formats where all languages are to be put in the same file, such
as Desktop files. That would not be really difficult to implement I
guess (po-debconf, a sister project of po4a does so), but I never took
the time to do so.


What I meant previously is that someone should try to come up with a
proof of concept (PoC) of TransTractors in Python, just to see how it
would look like. That should not be horrible, I guess. But maybe I'm
not fluent enough in Python to preview the difficulties.

Sorry for Ruby fans, but I strongly believe that we should stick for
the most common programming language to maximize the amount of
potential contributors. To rephrase it slightly: do not provide a Ruby
PoC if you're not serious about maintaining it in the next 10 years as
I'll personnally only commit myself in mainstream solutions for po4a.

Bye, Mt.

-- 
It is impossible to find the perfect research tool, in which you have
absolutely nothing to adapt for doing your own research. Unless the
tool designers scooped you and conducted this very study already. 
      -- Da SimGrid Team      
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20180216/44b4173e/attachment.sig>