Italian \ORDINALstring does not work.

[vincentb1]

MWE:

\documentclass[italian]{article}

\usepackage{babel}
\usepackage{fmtcount}

\begin{document}
\section{A}
\section{B}
\section{C}
\section{D}
\ordinalstring{section}
\Ordinalstring{section}
\ORDINALstring{section}
\end{document}

Output is basically something like:

1 A 2 B 3 C 4 D

quarto Quarto NOVANTADUESIMO

[vincentb1]

Not being a fluent Italian speaker, I speculate however that we should get « QUARTO » instead of « NOVANTADUESIMO », it seems that some counter is not reset somewhere — maybe the bug is not in fmtcount, but in the wrapped package.

[nlct]

Same result can be obtained without fmtcount:

\documentclass[italian]{article}

\usepackage{babel}
\usepackage{itnumpar}

\begin{document}
\printordinalem{4}

\MakeUppercase{\printordinalem{4}}
\end{document}

Some commands don't work inside case-changing commands. This may be an instance of one.

[vincentb1]

It seems that an \edef is sufficient to produce the issue, see:

\documentclass[italian]{article}

\usepackage{babel}
\usepackage{itnumpar}

\begin{document}
\printordinalem{4}

\edef\temp{\printordinalem{4}}
\temp

\makeatletter
\protected@edef\temp{\printordinalem{4}}
\temp
\makeatother
\end{document}

[vincentb1]

One (not so easy) way to fix it would be a complete re-write of italian based on the fcnumparser.sty engine. The other is to report it to E. Gregorio, and ask him to fix it…

[vincentb1]

I just made the report (lazy sigh…)

[nlct]

One (not so easy) way to fix it would be a complete re-write of italian based on the fcnumparser.sty engine.

There's no point re-inventing the wheel. I seem to remember that I once tried to add Italian to fmtcount from someone else's instructions (I don't know any Italian) but there were too many complicated cases, which is why I switched to just interfacing with itnumpar. Perhaps just put in a warning that the upper case version currently isn't supported for that language and just leave it as lower case.

[eg9]

The issue here is that the logic of itnumpar and fmtcount are reversed: my package starts with counters and uses this approach for printing numbers; fmtcount wants to do computations on counters by reducing them to computations on numbers.

[vincentb1]

@nlct @eg9 I think that have solved this issue, which is some sort of duplicate of bugs #13 and #14 in my latest commit.

Actually the issue was interfacing with itnumpar at the user API level rather than with lower level macros. Doing so was more portable and futureproof against itnumpar evolution, but implied not using fully expandable macros inside an \edef. There was also a bug in the fmtcount main part with not \protect-ing everything in some place.

So, it seems that this one is solved. We still have the limitation that itnumpar does not go beyond 9999 — that is why my statement about a complete rewrite based on fcnumparser is still valid. Since Italian is a latin language, just like in French there should be no limit on the numbers which you can litterate in Italian.

@nlct I have made the fix on the master branch which is under work because of Arabic (cc: @mfbellalouna)

If you are happy with the fix, I can cherry-pick it to branch version_3.5+ in order to publish the fix on CTAN.

[vincentb1]

@eg9 BTW, thank you for your valuable feedback.

[mfbellalouna]

Salut Vincent I absolutely don't understand what you're talking about ! Faouzi

Le dim. 14 juin 2020 à 00:07, Vincent Belaïche notifications@github.com a écrit :

@eg9 https://github.com/eg9 BTW, thank you for your valuable feedback.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nlct/fmtcount/issues/37#issuecomment-643678468, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI3GBLPU6L5J7MYGPZCE24TRWPTCFANCNFSM4FGFXBOA .