Re: [Po4a-devel] Changing programming languages

Hello, On Fri, Feb 09, 2018 at 10:04:58AM +0100, Brian Exelbierd wrote: 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