Hi, I agree with Mikel Artetxe that we should not have Java language
pairs that depend on external dependencies. The Java applications are
easy to install and use, and should stay like that. The Omega-T plugin
is quite useful, for instance.
I remember now that this was the decisive reason why I didn't try
to solve some of the problems with the pair sv-da by using
Constraint Grammar.
Maybe some kind of "back-porting" for the involved languages would be
possible until a more solid solution evolves?
Yours, Per Tunedal
On Thu, Mar 3, 2016, at 10:41, Mikel Artetxe wrote:
>
>
> On Tue, Feb 23, 2016 at 9:27 AM, Tino Didriksen
> <[email protected]> wrote:
>> I have updated all the pairs I could in
>> https://svn.code.sf.net/p/apertium/svn/builds with these omissions:
>>
>> apertium-ca-it no longer installs mode ca-it - bug, or should ca-it
>> be removed from language-pairs?
>>
>> apertium-eo-es mode es-eo now uses CG-3.
>>
>> apertium-fr-ca has since been renamed to fra-cat, but now uses CG-3.
>>
>> apertium-fr-es throws an exception when executing:
>> http://codepad.org/1eAyqhEL
> It looks there is an lrx-proc implementation in Java but is still
> experimental and not used. The dispatcher tries to invoke it as an
> external program and there is a bug that makes it crash (the -m flag
> is treated as a file and it is not found in the package when trying to
> extract it). I will fix the bug when I have time. But the important
> thing here is that lrx-proc is an external dependency, just as cg3 and
> hfst, so we should not have Java language pairs that depend on it
> (unless we use some mechanism to handle these dependencies as
> discussed below).
>
> --snip--
>
>> apertium-sv-da has since been renamed to swe-dan, but there is no
>> release with that name yet.
>>
>> And, I had to bump the used revision for en-es, eo-en, eo-fr, es-ca
>> because their releases were so old they no were no longer buildable.
>>
>> I made a script to do the updating for me
>> https://svn.code.sf.net/p/apertium/svn/builds/update-pairs.php which
>> pulls revisions from the packaging system, because that is currently
>> the best source of release information.
>>
>> I would like to add a 5th field to language-pairs which is a comma
>> separated list of extra dependencies needed for the pair, instead of
>> simply skipping them. E.g., "cg, hfst" for kaz-tat. Then systems that
>> can't install such dependencies can skip those pairs.
>
> Sounds good to me, but we should first update all the applications
> that make use of Java pairs to properly handle it and leave some time
> for users to update. Otherwise all the current applications would
> break. For instance, users would see new pairs in the official Android
> app and they would even be able to install them, but the app would
> crash when trying to run them. A dirty solution to avoid these
> problems would be to have a separate manifest file for language pairs
> with external dependencies. This way, current applications would keep
> working as they are, and we would still be able to update them to use
> pairs with external dependencies if possible.
>
> Mikel
> ----------------------------------------------------------------------
> --------
> -- snip--
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
