Hi,
please see my questions below.
Yours,
Per Tunedal

On Sun, Sep 23, 2012, at 17:10, Francis Tyers wrote:
> El dg 23 de 09 de 2012 a les 16:47 +0200, en/na Per Tunedal va escriure:
> > Hi,
> > existing one to many translations I've ran into by accident:
> > 
> > inte - ikke
> > icke - ikke
> > 
> > fru - kone
> > fru - frue
> > fru - fru
> > 
> > vid - bred
> > vid - rummelig
> > 
> > stad - by
> > stad - stad
> > 
> > New ones I've happened to add:
> > 
> > utdelning - fordeling (usage: distribution of e.g. bread, is this
> > correct?)
> > utdelning - uddeling (usage: share - information technology)
> > 
> > fungera - fungere (I don't know the difference in Danish)
> > fungera - virke
> > 
> > godkännande - accept (normal usage)
> > accept - accept (usage: finance/economy and legal)
> > 
> > And there are a lot more you can find by searching for RL and LR.
> > 
> > I have some more questions below.
> > 
> > Yours,
> > Per Tunedal
> > 
> > On Wed, Sep 12, 2012, at 16:24, Francis Tyers wrote:
> > > El dc 12 de 09 de 2012 a les 16:04 +0200, en/na Per Tunedal va escriure:
> > > > Hi again,
> > > > there already are some double translations in the pair Swedish (se) -
> > > > Danish (da). (In the new direction from Danish to Swedish.) I cannot
> > > > remove them, can I? Or should I comment them out!?
> > > 
> > > If they are valid translations, leave them. I've updated the modes file
> > > to use the -b mode which in the case of ambiguity picks the first
> > > translation.
> > 
> > Seems like a convenient way to treat the problem.
> > Which one is "the first"? Simply the one first in the bidix reading from
> > the top to the bottom or something else?
> 
> It's not predictable from the order in the bidix because of the
> compilation process. 

"the -b mode which in the case of ambiguity picks the first
translation" Thus the result is unpredictable? Such a solution doesn't
appeal to me.

> > > 
> > > Also, could you give examples ? It's easier to work things out with
> > > examples...
> > 
> > See above.
> > 
> > > 
> > > > How should I prepare for one to many translations? Or at least not put
> > > > any obstacles in the way of using Francis Tyers' new solution.
> > > 
> > > Leave them in.
> > 
> > OK. I might change the order, though. If that would improve the
> > translations.
> 
> Changing the order would not change the translation.
> 
> > Should I remove the original r="RL" and r="LR"? And the ones I've added?
> 
> You can do.

OK, but which one of the translations will be used?

> 
> > > 
> > > > I don't fully understand what you wrote, Francis:
> > > > 
> > > > > > Regarding the bilingual dictionaries, if you would like to use the
> > > > > > module in the future (please use it, it's cool!), then the most
> > > > > > important things are:
> > > > > > 
> > > > > > * add as many reliable translations as possible per word.
> > > > > > * do not use LR/RL for lexical selection -- only for grammatical 
> > > > > > stuff.
> > > > > > It is better to use i="yes", or slr="..." with the for translations 
> > > > ------------------------------------------------------------------------
> > > > > > which you don't want to pick. 

Is a word missing above? Do you mean something like:
 with the LINES/ENTRIES for translations which you don't want to pick?

If you use slr, you'll need the
> > > > > > lexchoicebil.xsl script.

I haven't found any documentation of the lexchoicebil.xsl script in the
Wiki.

> > > > > > 
> > > > > > You can choose to mark the default translation or not. In the case 
> > > > > > that
> > > > > > you don't mark it, it can be learnt.
> > > > 
> > > > I cannot use LR/RL in the wordlists? What can I do instead?
> > > 
> > > You can use LR/RL but not for translation divergence, just for
> > > grammatical divergence.
> > > 
> > > > > > It is better to use i="yes", or slr="..." with the for translations 
> > > > 
> > > > with the for translations? With the what?
> > > 
> > > Leave them in.
> > 
> > Please explain the tags i="yes" and slr="..."
> > I'm curious to my nature. That's my way of learning things. Sometimes it
> > might lead to a new solution for an old problem.
> 
> i="yes" means that when the dictionary is compiled, the entry is
> ignored.
> 
> slr="" is a way of marking distinct "senses" for words. In your examples
> above, that's probably what I'd use.
> 
> Fran
> 

I suppose the tags should be within the <e>-tag? Like this <e
slr="XXX">.

Senses? Is there any standard for that? Above I indicated domains.
That's easy, senses are a bit more complicated to explain in short. Do I
set codes for senses in the lexchoicebil.xsl script, or what?

Practical considerations:

1. Finally, when correcting the pair Swedish (se) - Danish (da), what
shall I do? Simply strip the RL and LR tags, or adding an slr-tag
instead?

2. Obviously, the sme-nob solution <e  srl="1">, and using a CG rule to
pick the alternative when needed, is out of the question for the Swedish
(se) - Danish (da) pair. But what's the best solution for the "pair"
Norwegian (nn/nb) - Swedish (se)?

I cannot entirely avoid the problem as there are already two to one
relations from the very start. I have to treat them when I meet them.

> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Apertium-stuff mailing list
> Apertium-stuff@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/apertium-stuff

------------------------------------------------------------------------------
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
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to