Hi,
Just to clarify, this was not the reason why Mitzuli was removed from the
Play Store, but some security vulnerability with a library I used for the
camera feature. But yeah, I can see the issue with the bytecode.
Not sure if (2) would do the trick though. First, I don't see why they
would
I have for a while tried to get the Apertium+Omega-T working for sme-smn,
> but with no results. My last attenpt (and bugfix from one of the involved
> developers, thanks!!) brought me to the point where I got a window telling
> there was a path problem.
>
If you tell me what the error message is
On Sun, Mar 6, 2016 at 8:33 AM, Per Tunedal
wrote:
> Hi Mikel,
> Would you include it in the Java-versions, if I make a back-port of
> swe-dan to sv-da?
> Is it a requirement that the new version would be "released"? What would
> qualify the new version of sv-da as a
Yes, it should be possible to use pairs that depend on hfst-proc with
apertium-omegat (as long as hfst-proc is installed, of course). The issue
you describe could be caused by a bug in lttoolbox-java that I fixed in
r44409 back in 2013, but the binaries of apertium-omegat were never
updated. The
> 2016-01-12 21:59 GMT+01:00 Mikel Artetxe <artet...@gmail.com>:
>
>> Hi,
>>
>> On Tue, Jan 12, 2016 at 11:59 AM, Mikel L. Forcada <m...@dlsi.ua.es>
>> wrote:
>>
>>> Dear all,
>>>
>>> I hope I am luckier this time with this is
Hi,
On Tue, Jan 12, 2016 at 11:59 AM, Mikel L. Forcada wrote:
> Dear all,
>
> I hope I am luckier this time with this issue.
>
I guess that you are ;). The issue is fixed now and I have also updated the
binary at
On Wed, Jun 10, 2015 at 12:03 PM, Tino Didriksen m...@tinodidriksen.com
wrote:
Pulling this part out to apertium-stuff, as it is more generally
applicable...
On 10 June 2015 at 01:12, Jacob Nordfalk jacob.nordf...@gmail.com wrote:
As I understand the wording the goal was to make sure the
On Mon, Jun 8, 2015 at 1:41 PM, Tino Didriksen m...@tinodidriksen.com
wrote:
We were thinking of a standardized solution, such as jcenter (or maven
central), which keeps track of dependencies, binary releases, platforms and
versions.
This makes Android developers able to use the library by
2015-06-07 18:36 GMT+02:00 Mikel L. Forcada m...@dlsi.ua.es:
Wow, that's great, thanks a million!
It would also be nice if someone could port this to the Apertium app in
Google Play,
Yes, it surely needs an update! I'll be on it, as soon as soon as things
have settled.
We are talking
Hi,
Those of you who use Apertium in your Android phone will probably know that
some language pairs are currently missing there, as HFST and CG are not
supported at the moment. The good news is that this could change soon!
So I have managed to build VISL CG3 for Android. The script I use for
Btw, I don't know if this is the right place for comments or feature
requests,
especially on a newly released app, but I have a suggestion:
You can open issues at GitHub for this kind of ideas, but it is ok if you
write to me as well ;)
The GF offline translator has this nice feature
Hi Apertiumers,
I just wanted to let you know that, after a year as a beta, Mitzuli has
finally been released today, and it is publicly available on Google Play.
For those of you who have not heard about it, Mitzuli is an Apertium based
translator app for Android with a nice user interface and
On Wed, Oct 29, 2014 at 10:37 AM, Kevin Brubeck Unhammer unham...@fsfe.org
wrote:
Mikel Artetxe artet...@gmail.com writes:
You could sign the language pairs with your public key when
uploading,
have the public key in the app, let the app download both language
pair
2) Even if you are able to refute my first point (and you probably are
;-)),
we would only be forced to publish the Installation Information.
According
to the license, “Installation Information for a User Product means any
methods, procedures, authorization keys, or other information
On Tue, Oct 28, 2014 at 6:26 PM, Benedikt Freisen b.frei...@gmx.net wrote:
Ok, I misunderstood that then.
Another option:
- download the language pairs using the app (the way it's done now)
- compute a hash value (e.g. SHA) and store it in app memory,
where it cannot be changed by other
You could sign the language pairs with your public key when uploading,
have the public key in the app, let the app download both language pair
and signature and check the signature.
That doesn't make much sense to me. In your schema the attacker would also
be able to sign his malicious code,
On Tue, Oct 28, 2014 at 11:03 PM, Jacob Nordfalk jacob.nordf...@gmail.com
wrote:
What a great discussion and great ideas !
I am really impressed by how much you care for how *others* could do to
abide to the license term.
Of course that we care about others, but it is not only that...
If I understood you correctly, using a language pair from Apertium was
more
or less like playing a video from a video player in terms of licensing,
as
GPL would consider both of them mere aggregation. The only thing that I
would be doing is verifying that this mere aggregation comes from
OK. Now I understand what you were referring to. But I think that what I
propose has nothing to do with Tivoization, because our signature would
not
be hardware checked but software checked, which means that anybody would
be
free to modify the app and skip the check if they wish. In
On Sun, Oct 26, 2014 at 7:56 PM, Jim O'Regan jore...@gmail.com wrote:
On 26 October 2014 15:05, Mikel Artetxe artet...@gmail.com wrote:
2) Cryptographically sign the bytecode and verify this signature every
time
that we load it. Probably not too hard to implement, but we would have
Resources in Android are non-code content (bitmaps, layouts, strings...)
that are part of an app. In this case, I guess that we are talking about
string resources, which are as you said like .po files.
I wouldn't like to sound rude, but I don't see the point of this project.
Just a few reasons
Hi Apertiumers,
You might have already heard something about it, but it has not been
presented properly yet...
So here is Mitzuli, a new Apertium app for Android! Unlike the official
Apertium app, which is mainly a technical demo aimed at developers, Mitzuli
has been designed with end users in
If we have a capable student apply, would you be willing to mentor them,
Mikel ?
First of all, I think that we would first need to better define the
project. Having said that, I would be more than willing to help as much as
I can, but I'm not sure if I would make an appropriate mentor for
The way I see it, there is no reason to create new low-level Java
libraries. It is a dead or dying platform, and good riddance. Awful
language to work with, with over-designed interfaces and horrible
performance. And it's not even that portable! There's a reason Java's
tagline was twisted to
Is this supposed to be fixed? I've noticed that api.apertium.org has been
up for some days, but I have not been able to register (I get this message:
Unexpected error. Please try again later or use another name), and it
seems that no language pair is available (
On Wed, Feb 5, 2014 at 7:46 AM, Per Tunedal per.tune...@operamail.comwrote:
Hi,
what about going a bit commercial? Many companies use a dual licence
model: GPL + proprietary (e.g. the small Swedish company that made MySQL
started that way).
I'm not the one who has to take this decision, but
A related question for Mikel:
How much work would it be to make Mitzuli support HFST and VislCG in
translators ? Would it be enough work to make a GSOC project do you
think ? It's a really sought-after feature here (in Tromsø).
If I'm not wrong this is something that has already been
On Wed, Feb 5, 2014 at 12:08 AM, Jimmy O'Regan jore...@gmail.com wrote:
On 04/02/2014, Francis Tyers fty...@prompsit.com wrote:
El dt 04 de 02 de 2014 a les 22:56 +0100, en/na Per Tunedal va escriure:
Hi,
last summer we got a nice app for Android devices, but that's no good
for my Ipad.
On Wed, Feb 5, 2014 at 8:25 AM, aboobacker sidheeque mk aboobackervyd
@gmail.com wrote:
What about a qt app , so that we can maintain same code base for
android ,iphone and blackberry
We already have a native (Java based) app for Android, and I guess that
it could be easily adapted for
(1) we could have reduced pairs by removing unusual (infrequent)
vocabulary, yes. Would you like to work on a method to do so? Where would
you get frequencies from?
Let's see: Apertium's language packs take about 5MB while Google
Translate's language packs take about 150MB. Do we need to make
On Mon, Mar 11, 2013 at 10:59 AM, Francis Tyers fty...@prompsit.com wrote:
Hello Apertiumers,
I just searched for Apertium today in Google, and got some odd results
that look like spam. See the image.[1] Is this just happening to me,
or is it a general problem ?
Fran
1.
On Wed, Mar 13, 2013 at 9:40 AM, Mikel L. Forcada m...@dlsi.ua.es wrote:
Apertiumers,
here's my idea #6:
(6) Write an offline Apertium plugin for Firefox or Chromium, if they
can launch Java plugins, based on apertium-caffeine but capable of
dealing with HTML.
Not sure if it is feasible.
On Mon, Feb 25, 2013 at 8:45 PM, Ilnar Salimzyan
ilnar.salimz...@gmail.comwrote:
Hello,
The pair I wanted to use apertium-viewer for was Kazakh-Tatar (mode
file is /incubator/apertium-kaz-tat/modes/kaz-tat.mode).
rm -rf ~/.java/.userPrefs/apertium* didn't solve all the problems. It
allowed
Ilnar, going to View-Options and checking Use external processing should
solve your problem. For the full explanation, see below.
On Fri, Feb 22, 2013 at 10:09 PM, Jacob Nordfalk
jacob.nordf...@gmail.comwrote:
Hi Ilnar,
2013/2/20 Ilnar Salimzyan ilnar.salimz...@gmail.com
Dear Apertiumers,
.
perhaps [a] make an interface in libreoffice for selecting translator,
[b] take text from a document and translate it using selected
translator. etc.)
I tend to think it is a bit too involved, but I'd like to hear what
Jacob, Mikel Artetxe, etc. think about the Java challenge and, if
present, any
On Wed, Oct 24, 2012 at 8:50 AM, Mikel L. Forcada m...@dlsi.ua.es wrote:
Mikel et al.:
On 23/10/12 18:46, Mikel Artetxe wrote:
The current version already escapes everything inside tags. For
instance, if the text to translate is this is a test, a is not
translated. Wasn't that what we
On Mon, Aug 20, 2012 at 1:49 PM, Per Tunedal per.tune...@operamail.comwrote:
Hi,
are multiple modes for different domains supported by the OmegaT plugin?
I don't really know what you are talking about... How would that work with
standard Apertium? When you say multiple modes for different
3) Develop a Java port of it. Probably the best solution but,
obviously, the hardest one to implement...
I believe there was some work on this last year in GSOC:
http://www.languagetool.org/gsoc2011/
I didn't know about it. But it seems that what they developed was a
conversion tool
Mikel Artetxe has explained that the OmegaT plug-in doesn't work for
language pairs that depends on programs that aren't a part of
lttoolbox-java. Six language pairs depend on the Constraint Grammar
package and are thus excluded, one of them is apertium-nn-nb. But sv-da
doesn't use any
On Tue, Aug 7, 2012 at 2:14 AM, Jimmy O'Regan jore...@gmail.com wrote:
On 6 August 2012 21:03, Jacob Nordfalk jacob.nordf...@gmail.com wrote:
A workaround would be to split the code up in several methods.
However, I think we first should look if the rule could be simplified or
something.
And, finally, the new versions of Apertium Caffeine and the OmegaT plugin
are here!!! You can download Apertium Caffeine
herehttps://apertium.svn.sourceforge.net/svnroot/apertium/builds/apertium-caffeine/apertium-caffeine.jar,
and the OmegaT plugin
On Mon, Aug 6, 2012 at 11:47 AM, Jimmy O'Regan jore...@gmail.com wrote:
On 6 August 2012 10:24, Mikel Artetxe artet...@gmail.com wrote:
apertium-es-ro: Document apertium-es-ro.trules-ro-es.xml does not
validate
against /usr/local/share/apertium/transfer.dtd
I can't find any instance
thank you for the OmegaT plugin! It works like a charm.
Nice to hear that you like it!
PS You wrote: 7 released pairs depend on external programs that aren't
part of lttoolbox-java (one depends on apertium-pn-recogniser, and the
other six on the Constraint Grammar package) and, thus, are
On Mon, Aug 6, 2012 at 4:41 PM, Jimmy O'Regan jore...@gmail.com wrote:
Thanks to the intrepid bug hunting work of Mikel Artetxe and Kevin
Unhammer (and, indirectly, Jacob Nordfalk, via lttoolbox-java's error
reporting), I've made bugfix releases available for the following
packages
On Mon, Aug 6, 2012 at 9:35 PM, Xavi Ivars x...@infobenissa.com wrote:
Mikel,
I guess they might be renamed to match other similar pairs like
es-ca_valencia.
And about this mode, could you please add it to es-ca jar file?
apertium-es-ca.jar already includes es-ca_valencia.mode as well as
Also, as far as I know, ca_valencia-es does not exist in apertium-es-ca
language pair...
xavi@xavi-vaio:~$ echo hola | apertium es-ca_valencia
hola
xavi@xavi-vaio:~$ echo hola | apertium ca_valencia-es
Error: Mode ca_valencia-es does not exist. Try one of:
ca-es
ca-es-multi
On Sat, Aug 4, 2012 at 7:54 PM, Mikel Artetxe artet...@gmail.com wrote:
On Sat, Aug 4, 2012 at 7:25 PM, Per Tunedal per.tune...@operamail.comwrote:
Hi again!
I would like to try the OmegaT plugin. Where can I find it?
https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012
Just one comment, in the language pair list in Portuguese, the English
language name appears with the firs letter capitalised, and not the
rest of languages. In this case (Portuguese), it shouldn't be
capitalised.
I wrote the code that generates titles for language pairs, and I don't
Few things have been added like App crash detection. Some device doesn't
have enough RAM to support cache feature for translation and hence get
crashed due to Low Memory. At the time of crash, App report it to app
preference and close itself gracefully. So in next run, advance feature
like
I've updated both apertium-caffeine and the OmegaT plugin for the
following (you can find them in the usual place):
Nevertheless I think the 'display ambiguity' option should be expelled
from Apertium-caffeine as end user will never use this option.
Done!
WRT formatters and deformatters
I guess that you are talking about this. I might be blind, but I
haven't been able to identify the relevant piece of code there...
You're right. Most of the work is done at the Apertium server when it
receives format=omegat.
Perhaps you can just use the
translate
Cool. Works like a charm. A minor quibble: I said I wanted it installed
in /tmp and it decided that every file in there was an already installed
language pair. Perhaps a regex identifying language pairs by name would be
very helpful.
I now look at the file extension to filter JAR files. I
So, basically, what we need is to not translate anything between
tags, right? For instance, if we have something like Ez dakit zer arraio
idatzi, we should avoid translating zer arraio... is that all we need?
If so, it shouldn't be too hard to achieve.
Yeah, turning all of that into a
Hi everybody!
As discussed in another thread, I've been working on self-contained
language pair packages as part of my GSoC project, which deals with the
embeddability of lttoolbox-java. This time I'm writing to the list in order
to present two new applications that I've developed based on that
Looks good, but ticking Mark ambiguity causes it to crash. :-(
Using the following test phrase:
I want to head off to the beach now. When will we go next?
Thank you for reporting it.
I've discovered that it is lttoolbox-java who crashes and not Apertium
Caffeine itself. The problematic
Thank you for your feedback Mikel! I've fixed some of the issues that you
have found (the new version is already uploaded):
*Apertium Caffeine*
Apertium Caffeine is a small, user-oriented Apertium client, similar in
concept to apertium-tolk, but which has some great advantages over it:
-
But for android, what I think, weh dont need standalone the language pair
jar which you have upload to
https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012/artetxem/packages/jars/
should
not contain whole compiled code of lttoolbox.
It should have Translator class for
'As usual' I wanted to add several language pairs into the same JAR file.
That would be cool.
But it isnt possible, as transfer_classes and classes.dex doesent have
language pair specific file names.
Yes, that's true. I think that the biggest problem here is classes.dex,
which cannot have a
I have been really troubled by the broken Apertium-viewer (special
characters like å ä ö é è ê didn't work). I even considered to correct
the program myself, but found that my knowledge in Python wasn't
sufficient.
I think that you are talking about
Hi everybody,
As some of you might know, I am working on the embeddability of
lttoolbox-java as part of my GSoC project (you can follow my progress
herehttp://wiki.apertium.org/wiki/User:Mikel/Embeddable_lttoolbox-java:_Progress).
The central part of the project consists of having standalone
I have tried this and it works great! It is an excellent idea.
Thank you!
It would also be nice if you could provide a pointer to where the Java
sources are...
It simply consists of lttoolbox-java with some extensions and adaptations
that I have been working on. You can currently find
Overall, make sure that your port can be published in Apples store.
As it has been said, the main problem to publish in the app store would
be the GPL license: Apple doesn't currently allow apps licensed under GPL
In any case, I think that working for iOS is still worth it. Jailbreak is
If you really really want to make a GUI on this, fine, OK. But I'd
expect it to not been usen very often and I'd only spend limited time on
it. And as command line script for group 1) I think a makefile/shell script
is more adequate.
Now I really understand you and you have definitely
Just mention that the main problem that I found when working on the iOS
prototype was the fact that there were several duplicated symbols. For
instance, each program (ltproc, interchunk, postchunk and so on) has
logically a main function but, since iOS apps must consist of a single
Lets put people in two rough groups:
1) Apertium core developers. They are each maintaining 2-5 of the 20-30
language pairs that gets updated once in a while (lets say a release once a
month, on average). They are used to use makefiles and scripts.
2) All opthers. Occational users of
OK. This would be my very first draft of the work plan:
Week 1-3: Adapt lttoolbox-java so that it can directly work with embedded
files without the need of copying them to a temporary directory.
Week 4: Make an API class that easily allows the translation of an
embedded language pair. Work
On Sun, Mar 25, 2012 at 6:34 AM, Jayamal De Vas Gunawardhana
jayamalde...@gmail.com wrote:
Hi Mikel..
I'm also new to the apertium project. I'm considering the project which
enables Apertium to the Android. Sorry for annoying you. I'm asking you a
help because I saw that u have completed
67 matches
Mail list logo