I've now converted apertium-cat, -por, -por-cat, and -es-pt to use the shared scripts. Many more repos can benefit from this. I also removed INSTALL from por's history, so that needs to be recloned.
Also simplified their configure.ac to the minimum required, and made use of CG-3's pkg-config. Once apertium-lex-tools, -separable, -anaphora, -recursive have pkg-configs, various configure.ac can be even further simplified. https://github.com/apertium/apertium/tree/master/scripts now also has translate-to-default-equivalent which is used in many pairs. It used to produce ISO-8859-1 outputs, but I fixed that to UTF-8. Changesets for inspection: https://github.com/apertium/apertium-por/commit/1bd676e6e1c51089bf435d6f31465184d2243558 https://github.com/apertium/apertium-cat/commit/0511ed02709c5011f02308e7b432cd9f40a63b2f https://github.com/apertium/apertium-por-cat/commit/2cfdd200cff9f94e05b57155f14879ad56a42780 https://github.com/apertium/apertium-es-pt/commit/da1f310ec0aabf0fe6d08cf6fe2da6de7d176616 I think only -por-cat uses both metalrx and metalrx-to-lrx, so if you want to merge their functionality it should be harmless enough. -- Tino Didriksen On Fri, 13 Sep 2019 at 03:39, Xavi Ivars <xavi.iv...@gmail.com> wrote: > El dv., 13 de set. 2019, 1:27, Kevin Brubeck Unhammer <unham...@fsfe.org> > va escriure: > >> >> So it seems the python script >> https://github.com/apertium/apertium/blob/master/scripts/apertium-metalrx >> lets you do <def-macro> with templates like {{pfoo}}: >> >> https://github.com/apertium/apertium-por-cat/blob/master/apertium-por-cat.cat-por.metalrx#L5 >> that the caller can replace: >> >> https://github.com/apertium/apertium-por-cat/blob/master/apertium-por-cat.cat-por.metalrx#L3223 >> >> Perhaps >> >> https://github.com/apertium/apertium/blob/master/scripts/apertium-metalrx-to-lrx.in >> should call both the XSLT and the python script? It seems they should be >> compatible, doing nothing if the special features aren't used. (If so, >> scripts/apertium-metalrx should probably be named somethingelse.py.) >> > > Yes, I built that python script as a quick hack to see if that could be > done, and never really improved or documented it. My bad. > > Originally, I tried extending somehow the xslt, but I after spending too > much time figuring it out, I decided to go with a simple python script. > > It's compatible with the xslt: if I remember correctly, it needs to be > applied before, but that's about it in terms of requirements. > > Personally, I'd also bundle xslt logic into the same script. I think > python is way more readable than xslt, but didn't do that either for > several reasons: > * xslt "was already there". It existed in the past, and whoever > implemented that in xslt had (probably) a good reason to > * new python dependency: didn't want to introduce python dependency to all > packages that used to use the xslt script > * consistency across pairs: if python was not added everywhere, the > alternative would be to have some pairs with that logic being done via the > xslt script and some others via the python one > > But I think now it's a good opportunity to consolidate, decide where we > want to go (I'd vote for python helper scripts), and try to document it. > > -- > Xavi Ivars > < http://xavi.ivars.me > > _______________________________________________ > Apertium-stuff mailing list > Apertium-stuff@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/apertium-stuff >
_______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
