On Sat, Aug 11, 2012 at 6:04 PM, Jacob Nordfalk <[email protected]>wrote:
> That being said, even if a language pair doesent work satisfactory for a
> release, that doesent mean that people won't find it usefull to play around
> with.
>
> If would be kinda nice to have da->sv available but with a proper warning
> that its unreleased (perhaps show a beta sign besides it). Users would need
> to enable to see unreleased pairs in the settings before they appeared.
>
> And with Mikels new support for external programs, I feel that we need to
> rethink the language pair list configuration file (/builds/language-pairs)
> a little.
>
> I think where should be a column with keywords, where 'unreleased' could
> imply that its an unreleased direction (like da->sv) and 'gc' could imply
> that it depends on that CG is available. We could add keywords to this
> column if we encounter new requirements, like HFST.
> Clients should discard lines with keywords they doesent support.
>
> Note that this would require some lines duplicated. Like after
>
> apertium-sv-da
> https://apertium.svn.sourceforge.net/svnroot/apertium/builds/apertium-sv-da/apertium-sv-da.jar
> file:apertium-sv-da-0.5.0.tar.gz sv-da
>
> we would have a extra line with
>
> apertium-sv-da
> https://apertium.svn.sourceforge.net/svnroot/apertium/builds/apertium-sv-da/apertium-sv-da.jar
> file:apertium-sv-da-0.5.0.tar.gz
> *da-sv unreleased*
>
>
>
> Mikel, this is just an idea. Implement as you please :-)
>
I like your idea. I think that we should adopt something like the new
column that you propose even if we don't start using it right now. This way
our programs would be ready to deal with language pairs that have some kind
of limitation, even if we don't release them now.
That being said, I'm not sure if uploading JARs for unreleased language
pairs (or language pairs that depend on external programs) would be too
useful. We can assume that the average end-user doesn't have CG installed
in his machine, nor it would like to translate between unreleased language
pairs that perform poorly. And the user who has successfully compiled and
installed CG, or wants to translate between unreleased language pairs, is
probably familiar with Apertium and computers in general. He could easily
create the packages by himself... it is as simple as running a bash script!
(well, there are also some prerequisites like having the Android SDK, I
need to write about all this in the wiki...) In other words, I consider
that the vast majority of users would never need something like that, and
the ones who might be interested on it are likely to have enough knowledge
to be able to create the packages by themselves without major
complications. What do you think?
But I think that we should definitely rethink the manifest file for
language pairs. When the user base gets bigger (for instance, when the
Android app is released at Google Play), it will be harder to reconsider
all this stuff since we will need to guarantee backward compatibility. And
I have had an idea about it... instead of directly parsing the manifest
file that lists the available language pairs, why don't we first look on a
more basic manifest file that contains information about it? I've thought
that we could have a "master" manifest file with only two columns: the
first one for keywords and the second one for the URL of the manifest file
that it points to. For instance, we could have something like this:
standard
https://apertium.svn.sourceforge.net/svnroot/apertium/builds/language-pairs
unreleased
https://apertium.svn.sourceforge.net/svnroot/apertium/builds/language-pairs-unreleased
cg
https://apertium.svn.sourceforge.net/svnroot/apertium/builds/language-pairs-cg
android
https://apertium.svn.sourceforge.net/svnroot/apertium/builds/language-pairs-android
The clients would look to the first column and, if they recognize and
support that keyword, they would continue parsing the manifest file at the
link that corresponds to it (they might need to parse several manifest
files). This way, it would be really easy to extend the current system. We
could create a completely new format for the manifest files for the
language pairs without any problem: we would just need to add a new tag to
it and the programs that support it would start using the new manifest
file, while the older versions would still be working. We could even move
everything (including the manifests) to somewhere else... It is a much more
flexible solution than the current one, and it might be really useful in
the future. We would need to think more about it, but I consider that we
should definitely adopt something like this... Don't you agree?
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
