Hi all, a couple of comments: (1) I am not advocating the use of XSLT. In fact, I think it is not a good idea to bundle code (even if it is XSLT) with a language pair. I would rather have a compiler that understands directly the higher level descriptions collectively called metadixes; it wouldn't be difficult to actually parametrize the different dialects of metadix and pass on those parameters to a compiler that would then do whatever is needed for the dictionary to compile (there is a single transfer compiler for .t1x, .t2x and .t3x, for instance).
(2) I am sure there are common features of all metadixes that can be unified so that transformations embedded into the language pair are minimal, and, if possible, declarative and not procedural. I did have, I think, a unifying proposal for "par"'s and "sa"''s I would encourage Apertiumers to think of ways to look for those common features to try to minimize the current anarchy (the other day I found it quite difficult to explain to a student why one used metadixes for en in en-es and didn't use them for es). I think we should make an effort in both directions. Currently, Apertium does not look good with so many dialects and ad-hoc embedded XSLTs, etc. And also, format proliferation makes it very hard to use automatic tools like apertium-dixtools, etc. Just my 0.02€ worth! Mikel 12/21/2010 01:43 PM, Jimmy O'Regan wrote: > > On 21 Dec 2010, at 12:04, Kevin Brubeck Unhammer<unham...@fsfe.org> > wrote: > >> Francis Tyers<fty...@prompsit.com> writes: >> >>> Hi! >>> >>> The problem with this is that there are so many different metadix >>> formats that it will be impossible to come up with one that covers >>> them >>> all. For example if I remember correctly how the "alt" works is >>> different in es-pt and in oc-es. I think it was decided that it was >>> desirable to have them functioning differently, or at least would >>> require substantial changes in either language pair to get a unified >>> format -- changes that without some push (and let's face it, cash) >>> are >>> not going to get made. >>> >>> On the other hand, implementing compound words gives us the chance to >>> strike while the iron is hot! We can make a (fairly innocuous >>> change -- >>> any language pair that does not have compounding will be unaffected) >>> before getting a plethora of different options and thus avoiding the >>> metadix problem for another set of issues. >>> >>> Btw, thinking about metadix I have some probably unpopular ideas, >>> thatwould preclude any standardisation. I think that maybe we >>> should not >>> have one format, but rather many _codified_ formats depending on the >>> language(group). For example how to include a verb would be >>> different in >>> Tajik and Dutch, because different things are important. Unnecessary >>> examples: >>> >>> <e lm="aanzitten"><par n="z/itten__vblex" prefix="aan" >>> pp="aangezeten"/></e> >>> >>> Giving: >>> >>> <e lm="aanzitten"><i>aanz</i><par n="aanz/itten__vblex_sep"/></e> >>> <e lm="aanzitten"><p><l>z</l><r>aanz</r></p><par >>> n="z/itten#_aan__vblex_sep"/><p><l><b/>aan</l><r></r></p></e> >>> <e lm="aanzitten"><p><l>aangezeten</l><r>aanzitten</r></p><par >>> n="gesproken__vblex_sep"/></e> >>> >>> Or in Tajik: >>> >>> <e lm="харидан"><par n="кард/ан__vblex" stem1="харид" stem2="хар"/ >>>> </e> >> In the unification proposal from >> >> http://wiki.apertium.org/wiki/Unification_of_metadix_and_parametrized_dictionaries#A_unifying_proposal >> >> the calls would look like >> >> <e lm="aanzitten"><par n="z/itten__vblex" prms="prefix='aan' >> pp='aangezeten'"/></e> >> >> and >> >> <e lm="харидан"><par n="кард/ан__vblex" prms="stem1='харид' stem2='х >> ар'"/></e> >> >> >> Are there good reasons not to go with that kind of syntax? > The use of the apostrophe, for one thing. Makes it unworkable for > several languages. The key/value pairs ought really to be expressed in > an XML structure. > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Apertium-stuff mailing list > Apertium-stuff@lists.sourceforge.net > https://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-03071 Alacant, Spain Phone: +34 96 590 9776 Fax: +34 96 590 9326 ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
