Hi again, Well, if the internal consistency is so important in Apertium, it's very odd that there isn't already from the very beginning an automatic way of trimming the dics, like depicted in the Wiki : http://wiki.apertium.org/wiki/Automatically_trimming_a_monodix . When I first learned of this, I was surprised that this was not somehow integrated in the build process.
As I found this counter-productive, I assumed that a solution would be to simply kill this darling. Anyhow, there are differences between monolingual dictionaries, other than the words included, that has to be somehow taken into account. For instance, the terminology might have to be standardized or "translated". This regards for instance genders of nouns and cases of pronouns. In my opinion, the terminology used in the language treated would be used, along with the equivalent in English. That would result in e.g. Akkusativ and Dativ for German and Objet direct et Objet indirect for French. I don't think it's any problem if the two (or more) monolingual dictionaries in a language pair use different terminology. In the bidix I simply use the conventions for the left language to the left and for the right language to the right. Or have I overlooked something? For example, the Norwegian monolingual dictionaries (nb/nn) use the cases nom=Nominativ, acc=Accusativ and gen=Genitiv, and the Swedish monolingual dictionary use the cases subj=Subjektsform, obj=Objektsform and gen=Genitiv. There isn't any need to change it, as far as I can see. Further the paradigms differ among versions. I still don't understand the implications of the different ways to treat personal pronouns in the monodix (and bidix!) between the pairs Icelandic (is) - Swedish (se) and Swedish (se) - Danish (da). The "icelandic" way looks more neat and elegant, though. Maybe some standardization would facilitate when creating new pairs. Yours, Per Tunedal On Fri, Oct 12, 2012, at 18:47, Francis Tyers wrote: > It's covered in the documentation, enjoy. > > http://wiki.apertium.org/wiki/Why_we_trim > > http://wiki.apertium.eu/index.php/Session_7 > > Fran > > El dv 12 de 10 de 2012 a les 16:46 +0200, en/na Per Tunedal va escriure: > > Hi, > > but you don't tell me the rational behind the requirement. I just don't > > get why it's worse to get "cannot translate" than "unknown word". > > Yours, > > Per Tunedal > > > > On Fri, Oct 12, 2012, at 07:37, Mikel L. Forcada wrote: > > > I am not in favour of dropping the requirement either. > > > Your PMC prez, > > > Mikel > > > > > > On 10/12/12, Francis Tyers <[email protected]> wrote: > > > > El dj 11 de 10 de 2012 a les 22:13 +0200, en/na Per Tunedal va escriure: > > > >> Hi, > > > >> I suggest more liberal requirements for release of a language > > > >> pair/direction: > > > >> > > > >> It would be sufficient if all words in the bilingual dictionary could > > > >> be > > > >> analysed, translated and generated. Drop the requirement that all words > > > >> in the source language monolingual dictionary should be translated. > > > >> > > > >> Rational: In that way you prepare for decoupling of the monolingual > > > >> dictionaries from the language pairs, see the ideas for Google summer > > > >> of > > > >> code, http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code: > > > >> > > > >> "Develop a method (scripts) to allow monolingual and bilingual data in > > > >> Apertium to be decoupled, leaving each language pair with only the > > > >> necessary bilingual data." > > > >> > > > >> In that way it would be easier to maintain the monolingual dictionaries > > > >> and all language pairs would immediately profit from a new contribution > > > >> to a monolingual dictionary. > > > >> > > > >> Besides, I just feel that it's really silly to drop entries from the > > > >> monolingual dictionaries to qualify for a release. > > > > > > > > It's a GSOC project, if someone takes it up, it would be great, but > > > > until then I don't see a reason to change the requirements. You can > > > > always use scripts to trim larger dictionaries as has been explained in > > > > previous posts. > > > > > > > > F. > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > Don't let slow site performance ruin your business. Deploy New Relic APM > > > > Deploy New Relic app performance management and know exactly > > > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > > http://p.sf.net/sfu/newrelic-dev2dev > > > > _______________________________________________ > > > > Apertium-stuff mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/apertium-stuff > > > > > > > > > > > > > > -- > > > Sent from Gmail for mobile | mobile.google.com > > > > > > Mikel L. Forcada E-mail: [email protected] > > > Departament de Llenguatges Phone: +34-96-590-9776 > > > i Sistemes Informàtics also +34-96-590-3772. > > > UNIVERSITAT D'ALACANT Fax: +34-96-590-9326, -3464 > > > E-03071 ALACANT, Spain. > > > > > > URL: http://www.dlsi.ua.es/~mlf > > > > > > ------------------------------------------------------------------------------ > > > Don't let slow site performance ruin your business. Deploy New Relic APM > > > Deploy New Relic app performance management and know exactly > > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > http://p.sf.net/sfu/newrelic-dev2dev > > > _______________________________________________ > > > Apertium-stuff mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/apertium-stuff > > > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > _______________________________________________ > > Apertium-stuff mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/apertium-stuff > > > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Apertium-stuff mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/apertium-stuff ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
