An update, to see where that blank comes from. If we have HTML tags (for
clarity), deleting the 'nie' just collapses them:
$ apertium -d . -f html af-nl
Hy sal nie kom<b><em>nie</em></b>.
Hij zal niet komen<b><em></em></b>.
The superblank <b><em> before the /nie/ is dealt with by no rule (it is
dealt with by the transfer engine between the rules, and is output
before the rule deleting the /nie/) and the superblank </em></b> is
dealt with by no rule (it is dealt with by the transfer engine between
the rules too). Therefore, there is no easy way to avoid the blank
before nie to appear before the period as far as I know.
Using the post-generator after .t3x probably can deal with the unwanted
blanks (sed could also deal with them by using a suitable regular
expression) but you might not want to remove tags such as <b><em> as the
result would be HTML with unbalanced tags (having <b><em></em></b>
before the period would actually be better than having just </em></b>).
I think this would call for some way in transfer to deal with
superblanks between rules (something like <b pos="0"/>?)
Another possibility would be a general "clean-up" module which does not
need to be woken up with "~".
I am sorry but I cannot come up with a nice solution using only Apertium
tools.
Mikel
Al 12/20/2011 04:11 PM, En/na Mikel Forcada ha escrit:
Pim:
I'm trying to fix an issue with the af-nl pair, namely that removing
"nie" at the end of a sentence leaves a space between the last word
and the period.
Have you tried to see where this extra space is added? I assume this
is a problem with a .t1x rule or similar dealing with nie, which does
not properly take care of superblanks. The rule <rule comment="REGLA:
nie"> is written in a way I cannot understand, with a *choose* that
only contains an *otherwise*. Apparently this rule checks whether a
negative has been seen before (using a state variable "seen_neg"
carried from rule to rule).
<equal>
<var n="seen_neg"/>
<lit v="true"/>
</equal>
and outputs a "nie" for a matched "nie" only if it has not been seen
before in the sentence. I would rewrite this rule reversing the
condition for "seen_neg" for a clearer code, and I would consider
adding a rule matching "nie .", that is, a nie at the end of a
sentence. This rule should deal with the superblanks (I would have to
think about this, as I cannot remember who deals with the superblank
before the "nie"!) to avoid the double blanks. I can give it a deeper
thought if needed.
Francis suggested and implemented a fix which involves
waking up the postchuncker by adding a ~ and then replacing " ~." with
"." This worked for some examples, but broke others.
Anyway, I personally think this is a syntactic/structural problem that
should be dealt with in the module that deals with
syntactic/structural transfer, and not inserting a post-generator
where it does not belong, but I tend to think that Francis maybe had a
reason to suggest this strange use, perhaps because superblank
management was not trivial in this case.
Cheers
Mikel
--
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
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Apertium-stuff mailing list
[email protected]
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
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
