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. 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... > 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. 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. -- Tino Didriksen
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
