[Apertium-stuff] Interest in working on Apertium GSoC project "Create a usable version for English - Igbo"

[Ndubuisi Onyemenam]

Hello World,
I am Ndubuisi Onyemenam, a Computer science student of Imo State
University. I was particularly excited while going through the GSoC project
list and seeing there was a project concerning my native language Igbo.

I am very much interested in working on this project. I  use an Ubuntu
System(Linux), and I am quite comfortable working with git, bash and xml. I
also speak and write English and Igbo fluently.

Here is a link to my Linkedin 
 and Github .

I look forward to hearing from persons in the organization.

Warm regards.

Ndubuisi Onyemenam.
Computer Science Department.
Imo State University, Owerri.
Nigeria.
___
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

[Apertium-stuff] Registration for wiki account

[Samrat Patel]

Hi,
I am working on "Improvement in Apertium Website" and wish to submit a
proposal for it, I request a wiki account with the username samrat2825.

Regards
Samrat Patel
___
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Re: [Apertium-stuff] GSOC 2020 idea

[Rajarshi Roychoudhury]

I have completed writing my gsoc proposal, can I get a wiki account?

Username: rroychoudhury
email: rroychoudhu...@gmail.com

On Fri, Mar 6, 2020, 21:40 Rajarshi Roychoudhury 
wrote:

> One is .odt format , the other in .pdf. Kindly give it a read and give
> suggestions.
> Best,
> Rajarshi
>
> On Fri, 6 Mar 2020 at 21:15, Francis Tyers  wrote:
>
>> El 2020-03-06 15:35, Scoop Gracie escribió:
>> > Sending it as .odt would be great.
>> >
>> > On Fri, Mar 6, 2020, 07:27 Rajarshi Roychoudhury
>> >  wrote:
>> >
>> >> Then how should I send the file. I don't know if there is anyone to
>> >> mentor this since this is not from the list of ideas mentioned .
>> >>
>> >> On Fri, Mar 6, 2020, 20:49 Francis Tyers 
>> >> wrote:
>> >>
>> >>> El 2020-03-06 08:40, Rajarshi Roychoudhury escribió:
>>  Hi,
>>  I have written my idea in the file attached . It is just the
>> >>> idea ,
>>  not the project proposal . Kindly read the idea and give
>> >>> feedback on
>>  whether this can be a feasible GSoC project.
>>  Best,
>>  Rajarshi
>> >>>
>> >>> Please do not use proprietary formats for attachments to this
>> >>> mailing
>> >>> list.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> Best regards,
>> >>>
>>
>> Or .txt or .pdf
>>
>> Fran
>>
>>
>> ___
>> Apertium-stuff mailing list
>> Apertium-stuff@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>
>
___
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Re: [Apertium-stuff] Apertium PMC elections

[Scoop Gracie]

oh wait. that's just auto generated from an ip

On Sun, Mar 22, 2020 at 6:47 PM Scoop Gracie  wrote:

> I found Ivy Richardson's email address.
> ivyrichard...@149-161-191-7.dhcp-bl.indiana.edu
>
> On Wed, Mar 18, 2020 at 11:23 AM Hèctor Alòs i Font 
> wrote:
>
>> I think that a delay as this one is not a problem at all. This seems to
>> me quite different to the case that was under discussion.
>> Hèctor
>>
>> Missatge de Tanmai Khanna  del dia dc., 18 de
>> març 2020 a les 21:03:
>>
>>> I'm not sure if this is about me at this point, but yeah I didn't mean a
>>> temporary resignation, which seems like trying to find a loophole, but as
>>> Tino said, a delayed appointment would've made more sense if I do get
>>> elected and my GSoC application gets accepted.
>>>
>>> Please let me know if that is acceptable to the community. If it's not,
>>> I'll pick one.
>>>
>>> Thanks
>>> Tanmai
>>>
>>> On Wed, Mar 18, 2020 at 11:16 PM Scoop Gracie 
>>> wrote:
>>>
 After reconsidering the temporary resignation, I will stop supporting
 it.

 On Wed, Mar 18, 2020, 10:40 Sushain Cherivirala 
 wrote:

> Thanks for the excellent summary of the situation, Election Board.
>
> I've given it some thought and decided to also run for the PMC. Please
> add my name to the ballot.
>
> I'll second the thoughts of Xavi and Ngadou -- a "temporary
> resignation" seems quite contrived to me.
>
> --
> Sushain K. Cherivirala
>
> On Wed, Mar 18, 2020 at 3:08 AM Ngadou Yopa 
> wrote:
>
>> I share the same idea with Xavir Ivars
>> You definitely have to choose one or the other.
>>
>> Thanks,
>> Ngadou
>>
>> Le mercredi 18 mars 2020, Scoop Gracie  a
>> écrit :
>>
>>> I don't think it violates the idea of the rules to leave and come
>>> back. I think the concern is so students don't manipulate things in 
>>> their
>>> own favor.
>>>
>>> On Tue, Mar 17, 2020, 16:12 Xavi Ivars  wrote:
>>>
 Do bylaws say something about being a over-18?

 I don't think it's explicit anywhere, but it would be something we
 should take into account.

 Also, I don't think temporary resignations (getting off the PMC
 while GSoC or GCI are going on and then coming back) is a good idea: 
 that
 seems to my trying to find a workaround to literally follow the rules 
 but
 in practice breaking them (just to be clear: I'm not taking about 
 "holding"
 on someone joining the PMC until their GSoC/GCI finish, but getting
 in/out/in the again).


 --
 Xavi Ivars
 < http://xavi.ivars.me >

 El dt., 17 de març 2020, 16:46, Scoop Gracie 
 va escriure:

> Oh, okay. There's a similar scenario with GCI; I want to be a
> student again this year. Could we keep a vacancy on the PMC from the 
> start
> of GCI until it ended?
>
> On Tue, Mar 17, 2020 at 8:40 AM Daniel Swanson <
> awesomeevildu...@gmail.com> wrote:
>
>> Given that GSoC applications have already begun, I think that
>> would amount to the same thing.
>>
>> On Tue, Mar 17, 2020 at 11:38 AM Scoop Gracie <
>> scoopgra...@gmail.com> wrote:
>>
>>> Alternatively, would it be possible for  him to be appointed
>>> now, temporarily resign before GSoC, and then be reappointed after 
>>> GSoC
>>> ends?
>>>
>>> On Tue, Mar 17, 2020 at 7:29 AM Tino Didriksen <
>>> m...@tinodidriksen.com> wrote:
>>>
 Tanmai Khanna is both standing for PMC and is considering
 participating as a student in GSoC for Apertium. These are 
 incompatible -
 GSoC rules state students cannot be officers of the organization 
 they want
 to work for.

 I propose that if Tanmai Khanna is both elected and applies and
 is accepted for GSoC, that we postpone his appointment to the PMC 
 until
 final GSoC evaluations are done. We discussed it a bit in the 
 mentors IRC
 channel.

 Just one more quirk to add to the mix.

 -- Tino Didriksen


 On Tue, 17 Mar 2020 at 09:33, Hèctor Alòs i Font <
 hectora...@gmail.com> wrote:

> According to article 23 of the by-laws,
>
> "f) When an election is called, the Election Board will
> publish a temporary census of Committers with right to vote will 
> be
> published.
> g) After 7 days to amend the census, a definitive census of
> Committers with right to vote will be published by the El

Re: [Apertium-stuff] Apertium PMC elections

[Scoop Gracie]

I found Ivy Richardson's email address.
ivyrichard...@149-161-191-7.dhcp-bl.indiana.edu

On Wed, Mar 18, 2020 at 11:23 AM Hèctor Alòs i Font 
wrote:

> I think that a delay as this one is not a problem at all. This seems to me
> quite different to the case that was under discussion.
> Hèctor
>
> Missatge de Tanmai Khanna  del dia dc., 18 de
> març 2020 a les 21:03:
>
>> I'm not sure if this is about me at this point, but yeah I didn't mean a
>> temporary resignation, which seems like trying to find a loophole, but as
>> Tino said, a delayed appointment would've made more sense if I do get
>> elected and my GSoC application gets accepted.
>>
>> Please let me know if that is acceptable to the community. If it's not,
>> I'll pick one.
>>
>> Thanks
>> Tanmai
>>
>> On Wed, Mar 18, 2020 at 11:16 PM Scoop Gracie 
>> wrote:
>>
>>> After reconsidering the temporary resignation, I will stop supporting it.
>>>
>>> On Wed, Mar 18, 2020, 10:40 Sushain Cherivirala 
>>> wrote:
>>>
 Thanks for the excellent summary of the situation, Election Board.

 I've given it some thought and decided to also run for the PMC. Please
 add my name to the ballot.

 I'll second the thoughts of Xavi and Ngadou -- a "temporary
 resignation" seems quite contrived to me.

 --
 Sushain K. Cherivirala

 On Wed, Mar 18, 2020 at 3:08 AM Ngadou Yopa 
 wrote:

> I share the same idea with Xavir Ivars
> You definitely have to choose one or the other.
>
> Thanks,
> Ngadou
>
> Le mercredi 18 mars 2020, Scoop Gracie  a
> écrit :
>
>> I don't think it violates the idea of the rules to leave and come
>> back. I think the concern is so students don't manipulate things in their
>> own favor.
>>
>> On Tue, Mar 17, 2020, 16:12 Xavi Ivars  wrote:
>>
>>> Do bylaws say something about being a over-18?
>>>
>>> I don't think it's explicit anywhere, but it would be something we
>>> should take into account.
>>>
>>> Also, I don't think temporary resignations (getting off the PMC
>>> while GSoC or GCI are going on and then coming back) is a good idea: 
>>> that
>>> seems to my trying to find a workaround to literally follow the rules 
>>> but
>>> in practice breaking them (just to be clear: I'm not taking about 
>>> "holding"
>>> on someone joining the PMC until their GSoC/GCI finish, but getting
>>> in/out/in the again).
>>>
>>>
>>> --
>>> Xavi Ivars
>>> < http://xavi.ivars.me >
>>>
>>> El dt., 17 de març 2020, 16:46, Scoop Gracie 
>>> va escriure:
>>>
 Oh, okay. There's a similar scenario with GCI; I want to be a
 student again this year. Could we keep a vacancy on the PMC from the 
 start
 of GCI until it ended?

 On Tue, Mar 17, 2020 at 8:40 AM Daniel Swanson <
 awesomeevildu...@gmail.com> wrote:

> Given that GSoC applications have already begun, I think that
> would amount to the same thing.
>
> On Tue, Mar 17, 2020 at 11:38 AM Scoop Gracie <
> scoopgra...@gmail.com> wrote:
>
>> Alternatively, would it be possible for  him to be appointed now,
>> temporarily resign before GSoC, and then be reappointed after GSoC 
>> ends?
>>
>> On Tue, Mar 17, 2020 at 7:29 AM Tino Didriksen <
>> m...@tinodidriksen.com> wrote:
>>
>>> Tanmai Khanna is both standing for PMC and is considering
>>> participating as a student in GSoC for Apertium. These are 
>>> incompatible -
>>> GSoC rules state students cannot be officers of the organization 
>>> they want
>>> to work for.
>>>
>>> I propose that if Tanmai Khanna is both elected and applies and
>>> is accepted for GSoC, that we postpone his appointment to the PMC 
>>> until
>>> final GSoC evaluations are done. We discussed it a bit in the 
>>> mentors IRC
>>> channel.
>>>
>>> Just one more quirk to add to the mix.
>>>
>>> -- Tino Didriksen
>>>
>>>
>>> On Tue, 17 Mar 2020 at 09:33, Hèctor Alòs i Font <
>>> hectora...@gmail.com> wrote:
>>>
 According to article 23 of the by-laws,

 "f) When an election is called, the Election Board will publish
 a temporary census of Committers with right to vote will be 
 published.
 g) After 7 days to amend the census, a definitive census of
 Committers with right to vote will be published by the Election 
 Board
 h) There will be 7 days for candidates to member and president
 to come forward
 i) The Election Board will proclaim the candidates to President
 and to Members of the Project Management Committee"
>>

Re: [Apertium-stuff] Lexd: a transducer compiler for prefixes and stuff

[Daniel Swanson]

On Mon, Feb 3, 2020 at 8:28 AM Kevin Brubeck Unhammer  wrote:
>
> Daniel Swanson
>  čálii:
>
> > https://github.com/mr-martian/lexd
>
> That's really interesting! I see it depends on lttoolbox, would it make
> sense to include it in lttoolbox perhaps?
>
> Can you explain a bit more about how it works / why it's faster? Perhaps
> in the README, along with the string "600x faster" ;)

I'm not sure how much detail to put, but there's now some explanation,
some diagrams, and some numbers in the README.

I also took a shot at making an option to output to lttoolbox bin
files but didn't fully make sense of the file format. Is there
documentation of it somewhere?


___
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Re: [Apertium-stuff] Working around monodix trimming

[Tanmai Khanna]

Hey Hèctor,
You're right, the task of creating a SL Lemma + TL morph is not a trivial
one, and as we discussed on the IRC recently, the task of eliminating
trimming is an essential first step towards that goal.

So as for the task for this GSoC, it would probably be to first eliminate
dictionary trimming, use the source analysis and output the source word
surface form (as an unknown) instead of source lemma. This would give us
the benefits of trimming without actually trimming. Then we can set the
foundations for a morph guessing idea, which can evolve over time - and
yes, initially it would be an optional module.

Thanks for your comments.

Tanmai

On Sun, Mar 22, 2020 at 2:38 PM Hèctor Alòs i Font 
wrote:

> I have some comments and questions from a simple Apertium user's point of
> view.
>
> In principle, I find the initial idea very useful: to go beyond trimming,
> maintaining its advantages, but keeping the source language information so
> that it is not lost for the transfer rules. Great!
>
> What I do not see so clearly is the (enormous) complication of inventing a
> word in the target language from more or less regular patterns in the
> target language (and maybe in the source too). If I understand correctly,
> it would be something like if we have, for example, "desaladoras" in
> Spanish, and we don't have this word in the bilingual dictionary. So the
> new module would try to produce something like "*desaladora's", or even
> "*desalators", "*dissalators" or "*dissaltators". And the same would be if
> the source and/or the target language are, say, Lingala, Tamil or Quechua.
> The more the target language has a complex morphology, the harder the task.
>
> This may be interesting, but the problem seems quite different from the
> first one and with a much higher degree of difficulty. I would separate the
> two issues. If we could ensure that we get a reliable tool for the first
> one, it would be very useful. If we also have a prototype for the second,
> which can be activated or not at the developer's discretion, it would be
> perfect.
>
> Hèctor
>
> Missatge de Mikel L. Forcada  del dia dg., 22 de març
> 2020 a les 10:25:
>
>> For suffixing or prefixing languages, you could expand the morphological
>> dictionary and use an algorithm such as OSTIA (1) to learn morphological
>> analyses for word endings.
>>
>> Mikel
>>
>> (1) Oncina, J., Garcia, P., Vidal, E., IEEE Trans Patt Recog Mach Intell
>> 15:5 (1993)448-458.
>>
>>
>>
>>
>>
>>
>> El 21 de març de 2020 21:12:16 CET, Tanmai Khanna <
>> khanna.tan...@gmail.com> ha escrit:
>>>
>>> Guessing the morphology would definitely require some creativity, but
>>> yes a guessing dictionary could be created. As mentioned, it would assign
>>> morphs to morphological analysis in the TL. The easiest (and the most
>>> naive) way to do this might be to take all the entries with that analysis
>>> and find a common substring. It will be more complex for morphemes that
>>> aren't prefix or suffixes or even process morphemes. However, to work
>>> towards a morph analyser that can assign morphs to analyses sounds like a
>>> good goal to work towards, and eliminating dictionary trimming is an
>>> essential step in that direction.
>>>
>>> Tanmai
>>>
>>> On Sat, Mar 21, 2020 at 9:48 PM Mikel L. Forcada  wrote:
>>>
 This looks interesting.

 Note that generating target language morphology may not always be
 possible, unless a "guessing" dictionary is created automatically from both
 the source and target dictionaries. A "guessing" dictionary would try to
 assign a morphological analysis to an unknown word by looking at the
 morphology of known words in the dictionary...

 This would be easy if one could, e.g. match suffixes to morphology in a
 suffixing language.

 Mikel


 El 21/3/20 a les 15:37, Tanmai Khanna ha escrit:

 Hey guys,
 Dictionary trimming is the process of removing those words and their
 analyses from monolingual language models (FSTs compiled from
 monodixes) which don't have an entry in the bidix, to avoid a lot of
 untranslated lemmas (with an @ if debugging) in the output, which lead to
 issues with comprehension and post-editing the output.

 There is a GSoC project
 
 which aims to eliminate this trimming and propose a solution such that you
 don't lose the benefits of dictionary trimming as well. In this email I
 will list a summary of the discussion that has taken place up until now.

 By trimming the dictionary, you throw away valuable analyses of words
 in the source language, which, if preserved, can be used as context for
 lexical selection and analysis of the input. Also, several transfer
 rules don't match as the word is shown as unknown.

 Several solutions are possible for avoiding trimming, some of which
 have been di

Re: [Apertium-stuff] Working around monodix trimming

[Hèctor Alòs i Font]

I have some comments and questions from a simple Apertium user's point of
view.

In principle, I find the initial idea very useful: to go beyond trimming,
maintaining its advantages, but keeping the source language information so
that it is not lost for the transfer rules. Great!

What I do not see so clearly is the (enormous) complication of inventing a
word in the target language from more or less regular patterns in the
target language (and maybe in the source too). If I understand correctly,
it would be something like if we have, for example, "desaladoras" in
Spanish, and we don't have this word in the bilingual dictionary. So the
new module would try to produce something like "*desaladora's", or even
"*desalators", "*dissalators" or "*dissaltators". And the same would be if
the source and/or the target language are, say, Lingala, Tamil or Quechua.
The more the target language has a complex morphology, the harder the task.

This may be interesting, but the problem seems quite different from the
first one and with a much higher degree of difficulty. I would separate the
two issues. If we could ensure that we get a reliable tool for the first
one, it would be very useful. If we also have a prototype for the second,
which can be activated or not at the developer's discretion, it would be
perfect.

Hèctor

Missatge de Mikel L. Forcada  del dia dg., 22 de març 2020
a les 10:25:

> For suffixing or prefixing languages, you could expand the morphological
> dictionary and use an algorithm such as OSTIA (1) to learn morphological
> analyses for word endings.
>
> Mikel
>
> (1) Oncina, J., Garcia, P., Vidal, E., IEEE Trans Patt Recog Mach Intell
> 15:5 (1993)448-458.
>
>
>
>
>
>
> El 21 de març de 2020 21:12:16 CET, Tanmai Khanna 
> ha escrit:
>>
>> Guessing the morphology would definitely require some creativity, but yes
>> a guessing dictionary could be created. As mentioned, it would assign
>> morphs to morphological analysis in the TL. The easiest (and the most
>> naive) way to do this might be to take all the entries with that analysis
>> and find a common substring. It will be more complex for morphemes that
>> aren't prefix or suffixes or even process morphemes. However, to work
>> towards a morph analyser that can assign morphs to analyses sounds like a
>> good goal to work towards, and eliminating dictionary trimming is an
>> essential step in that direction.
>>
>> Tanmai
>>
>> On Sat, Mar 21, 2020 at 9:48 PM Mikel L. Forcada  wrote:
>>
>>> This looks interesting.
>>>
>>> Note that generating target language morphology may not always be
>>> possible, unless a "guessing" dictionary is created automatically from both
>>> the source and target dictionaries. A "guessing" dictionary would try to
>>> assign a morphological analysis to an unknown word by looking at the
>>> morphology of known words in the dictionary...
>>>
>>> This would be easy if one could, e.g. match suffixes to morphology in a
>>> suffixing language.
>>>
>>> Mikel
>>>
>>>
>>> El 21/3/20 a les 15:37, Tanmai Khanna ha escrit:
>>>
>>> Hey guys,
>>> Dictionary trimming is the process of removing those words and their
>>> analyses from monolingual language models (FSTs compiled from
>>> monodixes) which don't have an entry in the bidix, to avoid a lot of
>>> untranslated lemmas (with an @ if debugging) in the output, which lead to
>>> issues with comprehension and post-editing the output.
>>>
>>> There is a GSoC project
>>> 
>>> which aims to eliminate this trimming and propose a solution such that you
>>> don't lose the benefits of dictionary trimming as well. In this email I
>>> will list a summary of the discussion that has taken place up until now.
>>>
>>> By trimming the dictionary, you throw away valuable analyses of words in
>>> the source language, which, if preserved, can be used as context for
>>> lexical selection and analysis of the input. Also, several transfer
>>> rules don't match as the word is shown as unknown.
>>>
>>> Several solutions are possible for avoiding trimming, some of which have
>>> been discussed by Unhammer here
>>> . These involve keeping
>>> the surface form of the source word, and the lemma+analysis as well - use
>>> the analysis till you need it in the pipe and then propagate the source
>>> form as an unknown word (like it would be done in trimming).
>>>
>>> Another interesting solution that was discussed was that instead of just
>>> propagating the source surface form, we can output [source-word lemma +
>>> target morphology], as is shown in this example by Mikel:
>>>
>>> Translating from Basque to English:
>>> "Andonik izarak izeki zuen" ('Andoni hung up the sheets') → 'Andoni
>>> *izeki-ed the sheets".
>>>
>>> This might help in comprehensibility of the output, and to some extent
>>> even the post-editability.
>>>
>>> If you have any significant pros, cons, or suggestions to add f

Re: [Apertium-stuff] Working around monodix trimming

[Mikel L. Forcada]

For suffixing or prefixing languages, you could expand the morphological 
dictionary and use an algorithm such as OSTIA (1) to learn morphological 
analyses for word endings.

Mikel

(1) Oncina, J., Garcia, P., Vidal, E., IEEE Trans Patt Recog Mach Intell 15:5 
(1993)448-458.






El 21 de març de 2020 21:12:16 CET, Tanmai Khanna  ha 
escrit:
>Guessing the morphology would definitely require some creativity, but
>yes a
>guessing dictionary could be created. As mentioned, it would assign
>morphs
>to morphological analysis in the TL. The easiest (and the most naive)
>way
>to do this might be to take all the entries with that analysis and find
>a
>common substring. It will be more complex for morphemes that aren't
>prefix
>or suffixes or even process morphemes. However, to work towards a morph
>analyser that can assign morphs to analyses sounds like a good goal to
>work
>towards, and eliminating dictionary trimming is an essential step in
>that
>direction.
>
>Tanmai
>
>On Sat, Mar 21, 2020 at 9:48 PM Mikel L. Forcada 
>wrote:
>
>> This looks interesting.
>>
>> Note that generating target language morphology may not always be
>> possible, unless a "guessing" dictionary is created automatically
>from both
>> the source and target dictionaries. A "guessing" dictionary would try
>to
>> assign a morphological analysis to an unknown word by looking at the
>> morphology of known words in the dictionary...
>>
>> This would be easy if one could, e.g. match suffixes to morphology in
>a
>> suffixing language.
>>
>> Mikel
>>
>>
>> El 21/3/20 a les 15:37, Tanmai Khanna ha escrit:
>>
>> Hey guys,
>> Dictionary trimming is the process of removing those words and their
>> analyses from monolingual language models (FSTs compiled from
>monodixes)
>> which don't have an entry in the bidix, to avoid a lot of
>untranslated
>> lemmas (with an @ if debugging) in the output, which lead to issues
>with
>> comprehension and post-editing the output.
>>
>> There is a GSoC project
>>
>
>> which aims to eliminate this trimming and propose a solution such
>that you
>> don't lose the benefits of dictionary trimming as well. In this email
>I
>> will list a summary of the discussion that has taken place up until
>now.
>>
>> By trimming the dictionary, you throw away valuable analyses of words
>in
>> the source language, which, if preserved, can be used as context for
>> lexical selection and analysis of the input. Also, several transfer
>rules
>> don't match as the word is shown as unknown.
>>
>> Several solutions are possible for avoiding trimming, some of which
>have
>> been discussed by Unhammer here
>> . These involve
>keeping
>> the surface form of the source word, and the lemma+analysis as well -
>use
>> the analysis till you need it in the pipe and then propagate the
>source
>> form as an unknown word (like it would be done in trimming).
>>
>> Another interesting solution that was discussed was that instead of
>just
>> propagating the source surface form, we can output [source-word lemma
>+
>> target morphology], as is shown in this example by Mikel:
>>
>> Translating from Basque to English:
>> "Andonik izarak izeki zuen" ('Andoni hung up the sheets') → 'Andoni
>> *izeki-ed the sheets".
>>
>> This might help in comprehensibility of the output, and to some
>extent
>> even the post-editability.
>>
>> If you have any significant pros, cons, or suggestions to add for
>this
>> project, you're requested to reply to this thread so that if I work
>on this
>> project, I can do it fully informed.
>>
>> Thanks and Regards,
>> Tanmai Khanna
>>
>> --
>> *Khanna, Tanmai*
>>
>>
>> ___
>> Apertium-stuff mailing
>listApertium-stuff@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>
>> --
>> Mikel L. Forcada  http://www.dlsi.ua.es/~mlf/
>> Departament de Llenguatges i Sistemes Informàtics
>> Universitat d'Alacant
>> E-03690 Sant Vicent del Raspeig
>> Spain
>> Office: +34 96 590 9776
>>
>> ___
>> Apertium-stuff mailing list
>> Apertium-stuff@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>
>
>
>-- 
>*Khanna, Tanmai*

-- 
Enviat des del meu dispositiu Android amb el K-9 Mail. Disculpeu la brevetat.___
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff