Missatge de Tanmai Khanna del dia dv., 4 de set.
2020 a les 9:22:
> Hèctor,
> Yes, the new improvements aren't backwards compatible but that's because
> they're better than the system we had earlier. Here's the changes:
>
> So, you are saying that the new stuff is not backwards compatible, aren't
Hèctor,
Yes, the new improvements aren't backwards compatible but that's because
they're better than the system we had earlier. Here's the changes:
So, you are saying that the new stuff is not backwards compatible, aren't
> you? There aren't any in the rule, but , which is not
> the same. Until n
Missatge de Tanmai Khanna del dia dj., 3 de set.
2020 a les 23:10:
> Hèctor,
> The extra blank there is because there's a blank in your rule output. See:
>
> $ echo "^052/052$^F/F$" | apertium-transfer
> -z -b 'apertium-fra-frp.frp-fra.t1x' 'frp-fra.t1x.bin'
>
> ^num_n{^052$ ^F$}$
>
>
> The rule
Hèctor,
The extra blank there is because there's a blank in your rule output. See:
$ echo "^052/052$^F/F$" | apertium-transfer
-z -b 'apertium-fra-frp.frp-fra.t1x' 'frp-fra.t1x.bin'
^num_n{^052$ ^F$}$
The rule for num_n has a in the rule output and hence there's a space.
The reason earlier the
Hi Tanmai,
Yes, hyphens and quotes (") seem to be solved. But the system persists to
add blanks where there were not. For instance, this causes that we get now
strange Unicode codes:
05076. Table des caractères Unicode U+0500 à U+052F.
< 05076. Tâbla des caractèros Unicode *U+0500 a *U+052F.
---
Hèctor can you check the page on beta now? The hyphen and the superscript
issues are solved. Of course, there's now a space between l and ér. If
that's a big problem we can discuss other solutions.
*तन्मय खन्ना *
*Tanmai Khanna*
On Thu, Sep 3, 2020 at 8:09 PM Tino Didriksen
wrote:
> I have adj
I have adjusted Transfuse with how spaces are treated for Apertium, and
implemented adding temporary spaces around and . Changes are
deployed on beta.
I repeat my plea that all symbols should have an analysis. It breaks markup
that things like - and : are not tokens.
-- Tino Didriksen
On Wed,
Tanmai Khanna
čálii:
>> So currently if I have the multiword "i dag", it'll recognize
> "idag" but it won't recognize "i dag"? (And I suppose if
> I have the non-multiword "today" it won't recognize "today".)
>
> Exactly, but even when it recognises "idag", the will probably
> be lost because it
> So currently if I have the multiword "i dag", it'll recognize
"idag" but it won't recognize "i dag"? (And I suppose if
I have the non-multiword "today" it won't recognize "today".)
Exactly, but even when it recognises "idag", the will probably
be lost because it's being seen as a normal blank.
Tanmai Khanna
čálii:
> the analyser sees wordbound blanks as normal blanks,
So currently if I have the multiword "i dag", it'll recognize
"idag" but it won't recognize "i dag"? (And I suppose if
I have the non-multiword "today" it won't recognize "today".)
One possibility might be to have wordb
Oh I see the hyphen thing. That should've been fixed after the latest
commit. Will check it out.
*तन्मय खन्ना *
*Tanmai Khanna*
On Thu, Sep 3, 2020 at 12:34 PM Tanmai Khanna
wrote:
> Hey,
> As of now, the analyser sees wordbound blanks as normal blanks, and so
> when they occur, the dictionary
Hey,
As of now, the analyser sees wordbound blanks as normal blanks, and so when
they occur, the dictionary will often not recognise multiwords. The reason
this was done was because we are offloading multiwords to
apertium-separable anyway. As for Iér, given that Tino Didriksen
is able to fix this
12 matches
Mail list logo
