+a/+aar invalid tag

[TinoDidriksen]

/usr/share/giella-core/scripts/taglist2make_CG_tags_regex.sh disamb-tags.txt > make-disamb-CG-tags.regex
ERROR:
The following tags do not follow the Giella tag conventions
(either +TAG, TAG+ or +TAG+) and can not be converted to the CG
format required for proper tokeniser functionality within the
Giella infrastructure:

+a/+aar
make[4]: *** [Makefile:865: make-disamb-CG-tags.regex] Error 1

[Trondtr]

The tag is from lang-esu. The fix is to change the tag there (discuss with the main developer first). I will have a look (or you may).

[snomos]

This is source code contributed and maintained by others than GiellaLT people. Do not change the code without thorough discussions with the author 🙂

[Trondtr]

Yes, this is a good advice.

While preparing for that, I glue in the full set of multichar symbols. They are different from ours. Could you have a look and tell what tags (tag types, rather) cannot be converted to CG format?

My general view is that tags should be transparent and groupable. But let step one be the formal aspect. So: Which of these (types) cannot be handled? (see next comment)

[Trondtr]

(ar)
(ar*)
(e)
(g)
(g/t)
(ng)
(r)
(r/l)
(s)
(t)
(u)
(u/i)
(ʼa)
+a/+aar
+c/.s
+c/.ss
+ciqe/@⁵ciiqe
+p/.v
+pegun/.vkun
+t/.s
@%:~(ng)ạ
@+(r/l)i
@+–'(g)ar(ar)te
@nga
@²
@³
@³%:(u)cir/@⁵cir
@¹
@ʸ
@ˁ
@ˡ
@⁴
@⁵
@⁵+cete/.vkar
@⁵+p/~v
@–ngr(ar)
@ˡ~+lu/@⁵na
[1DuPoss]
[1Du]
[1PlPoss]
[1Pl]
[1SgPoss]
[1Sg]
[2DuPoss]
[2Du]
[2PlPoss]
[2Pl]
[2SgPoss]
[2Sg]
[3DuPoss]
[3Du]
[3PlPoss]
[3Pl]
[3SgPoss]
[3Sg]
[4DuPoss]
[4Du]
[4PlPoss]
[4Pl]
[4SgPoss]
[4Sg]
[A_1Du]
[A_1Pl]
[A_1Sg]
[A_2Du]
[A_2Pl]
[A_2Sg]
[A_3Du]
[A_3Pl]
[A_3Sg]
[A_4Du]
[A_4Pl]
[A_4Sg]
[Abl]
[Abl_Mod]
[Abs]
[Cardinal]
[Cnsq]
[Conc]
[Cond]
[Cont]
[CtmpII]
[CtmpI]
[DemAdv]
[DemPro]
[DuPosd]
[Du]
[Encl]
[Equ]
[FUT]
[Ignorative]
[Imprs_Agnt]
[Ind]
[Intr]
[Intrg]
[Loc]
[NEG]
[N]
[Num]
[N→N]
[N→V]
[Opt]
[Opt_PRS_A_2Sg]
[Opt_PRS_A_2Sg_P_1Sg]
[Opt_PRS_A_2Sg_P_3Sg]
[Opt_PRS_S_2PlDu]
[Opt_PRS_S_2Sg]
[Ordinal]
[PRS]
[P_1Du]
[P_1Pl]
[P_1Sg]
[P_2Du]
[P_2Pl]
[P_2Sg]
[P_3Du]
[P_3Pl]
[P_3Sg]
[P_4Du]
[P_4Pl]
[P_4Sg]
[Particle]
[PerPro]
[PlPosd]
[Pl]
[Positional]
[Prec]
[Ptcp]
[Quant_Qual]
[Rel]
[STE_2Sg]
[S_1Du]
[S_1Pl]
[S_1Sg]
[S_2Du]
[S_2Pl]
[S_2Sg]
[S_3Du]
[S_3Pl]
[S_3Sg]
[S_4Du]
[S_4Pl]
[S_4Sg]
[Sbrd]
[Sec_Ter]
[SgPosd]
[Sg]
[Symbol]
[Ter]
[Trns]
[Unpd]
[V]
[Via]
[V→N]
[V→V]
[V→XCLM]
[e]
[how.V]
g̲
g̲g̲
k̲
q̲
r̲
r̲r̲
–lria/@⁴+ngur*
–r̲(ur)lur
–r̲pag/@²vag

[ftyers]

Ping @lonnystrunk :)

[TinoDidriksen]

This is still an issue.

[Trondtr]

Taking one step back, it seems the coded does not contain any +a/+aar tag, but a +a|+aar tag is declared in the multichar section... What I find is lines like this (line 292) in srcV2/esu.lexc:

carve-–a|–ar|–aa|+a|+aar[V→V]:carv%<+ar VerbPostbase; !
fg
thus it seems we somewhere pick the +... strings and convert the "|" to "/".

I have now gone through the code, I found 6 +a|+aar and changed them to +a|.aar (in line with all other +x|.yzx tags in the code), I do make distclean && make, but the same complaint for +a/+aar comes up nonetheless.

I contacted @lonnystrunk, let us see. It would be nice to get the fst off the groumd. In any case, the mystery is where the +a/+aar is created.