On Wed, Jun 10, 2015 at 12:03 PM, Tino Didriksen <[email protected]> wrote:
> Pulling this part out to apertium-stuff, as it is more generally > applicable... > > On 10 June 2015 at 01:12, Jacob Nordfalk <[email protected]> wrote: > >> As I understand the wording the goal was to make sure the >> platform-independt JAR files >> <http://wiki.apertium.org/wiki/Language_pair_packages#List_of_ready-to-use_packages> >> (here >> is for example eo-en >> <https://svn.code.sf.net/p/apertium/svn/builds/apertium-eo-en/>) and >> Mikel's simple list of language-pairs >> <https://svn.code.sf.net/p/apertium/svn/builds/language-pairs> was up to >> date, using the apertium-pack-j tool that Mikel made. >> But that's Java so I didnt really beleive that much would happen here ;-) >> > > The Debian builds can be used by the Java code as-is, but I can certainly > automatically repack them as JAR if needed, optionally with a JNLP and > classes. > You would also have to generate the java bytecode for transfer ( http://wiki.apertium.org/wiki/Bytecode_for_transfer) and convert it to dalvik bytecode for android. The current packages also include a copy of lttoolbox-java to make them self-contained executables, but maybe that's not very useful. Got the code for that already, from when I experimented with using zip for > Simpleton before settling on just bundling 7-Zip to ensure smaller > downloads. http://commons.apache.org/compress/ could do the same in Java. > > No way should any of this go in svn, though - keep binaries out of svn. > Maybe we should create http://files.apertium.org/ as a CNAME alias to > http://apertium.projectjj.com/ for future stability and nicer branding. > > Also apy.apertium.org -> apy.projectjj.com. > https://www.apertium.org/apy/listPairs already exists, but is a slower > reverse proxy. > > Hm, or also create rproxy https://www.apertium.org/files/ so that it can > be HTTPS. Options, options... > In my case I use sourceforge's file release system for mitzuli packages and it works ok. However, I think that the https thing is important here. As said before, the java language pair packages include bytecode for transfer, so a code injection attack would be possible in a man-in-the-middle schema. IIRC this was discussed in another thread. In Mitzuli I implemented a signature verification mechanism to prevent them but, without that, the only secure solution is to use https. But maybe it's just that I'm too paranoid about these things and we shouldn't worry too much about it! What you are required to do is to keep the simple list of language-pairs >> <https://svn.code.sf.net/p/apertium/svn/builds/language-pairs> up to >> date and expand it when there are new releases that can be executed by the >> platform indepent Java version. >> >> Mikel is working on a more rich list >> <https://github.com/artetxem/mitzuli/commit/7536c9f286eeb717eb59b4ef70bf5790c94e476d> >> needed >> by his Mitzuli work, and I want to get a discussion started on how to >> replace the current simple list by something usefull for all the use cases. >> In particular I would like to have the pairs in nursery and staging >> included in the list, but with a proper warning, and mark those pairs that >> needs extra software (such as CG) and whether the pair can work without it, >> but with degraded quality (as is the case of many pairs using CG as a >> preburner for the tagger). But that's another discussion. >> > > You mean > https://github.com/artetxem/mitzuli/blob/master/app/src/main/res/raw/manifest.xml > I assume. > He probably does :P I think that it won't be easy to come with a solution that works for everybody though. In the case of mitzuli, there are some things that don't fit apertium at all: tesseract based OCR packages, other MT engines (so far only through online APIs)... and I don't even use one package per language pair but per translation direction. I guess that other projects will have other needs, so I don't think that a universal solution exists here. In my opinion, Apertium's system should be designed with Apertium's own needs and criteria in mind, without worrying too much about the particular needs of other projects (because these needs will change and other projects with other needs will come) but trying to make it open and general, of course. In my case, this would probably mean that I wouldn't be using this system in Mitzuli directly, but I would love to be able to create my manifest and packages semi-automatically based on the ones from Apertium instead of building them from scratch. This would reduce the duplicated maintenance work to the minimum, and I think that that's the point here after all. This can all be auto-generated on-the-fly, a'la > http://apertium.projectjj.com/osx/nightly/data.php . Whether a pair needs > CG or HFST is already present in the package manifest and mode files, so > pulling that out to a list is trivial. > > And any pair that builds can be added to the service. There is one nursery > pair so far (tat-rus). I can automatically add appropriate warnings based > on what folder they came from. > > > >> Also not really relevant, as pair developers mark releases. But, as soon >>> as something was marked as a release, I pushed that onwards to Debian as >>> the stable package. >>> >> >> I might be the only one, but I dont know how to mark a release, and Google >> doesent help >> <https://www.google.dk/search?q=apertium+how+to+mark+a+release&oq=apertium+how+to+mark+a+release&aqs=chrome..69i57.9404j0j7&sourceid=chrome&es_sm=122&ie=UTF-8>. >> Is it just to follow the steps in >> http://wiki.apertium.org/wiki/Making_a_release ? >> > > That sounds good. So far, I've just caught them in the svn commit messages. > > But, all I need is an svn revision. If someone tells me apertium-x-y at > revision N is the latest release, that's sufficient. I don't even look at > .tar.gz bundles or copies made in /tags, but those are nice for other > people and uses. > This might be off topic but I am interested on that! I have always thought that releases were the tarballs in the sourceforge files, so released language pairs would be those with a tarball there and also the ones in trunk. But then there are some language pairs that are in trunk but don't have a tarball (like apertium-hbs-mkd) and some others that have a tarball but are not in trunk (like apertium-ht-en). Could somebody clarify that? Mikel
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
