Babel invoke inputenc where inputenc is not designed for xetex or luatex

[outlook user]

This doesn't correct the UTF-8 errors. This is supposed to correct them or only ensuring compilation upon recovery of errors?
________________________________
De : David Carlisle <d.p.carlisle at gmail.com>
Envoyé : dimanche 12 mai 2024 15:51
À : outlook user <RACP at outlook.fr>
Cc : texhax at tug.org <texhax at tug.org>
Objet : Re: Babel invoke inputenc where inputenc is not designed for xetex or luatex

in texlive 20204 (and probably all earlier versions)
any use of \usepackage[arabic]{babel}  will raise errors with
lualatex or xelatex as the arabi package files are not in UTF-8
You should raise this with the arabi package maintainer.

with lualatex:

(/usr/local/texlive/2024/texmf-dist/tex/latex/arabi/arabicore.sty
  Arabi Core switching commands v1.0  2006/01/01   (may still change)
! String contains an invalid utf-8 sequence.
l.137 \ifcase#1\or
                 ��������� � \ \or �����������^^@�^^@^^@

xelatex recovers from that but then errors on

! Package inputenc Error: inputenc is not designed for xetex or luatex.
(inputenc)                only UTF-8 supported.




I _think_ the recommended way to specify the language these days is

\documentclass{article}

\usepackage{babel}
\babelprovide{arabic}

\begin{document}

x
\end{document}

which allows babel to keep control.


On Sun, 12 May 2024 at 14:31, outlook user <RACP at outlook.fr<mailto:RACP at outlook.fr>> wrote:
> (inputenc)                only UTF-8 supported.
>
> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...
>
> l.164 \endinput

> For xelatex or lualatex save the document in UTF-8 encoding
> and do not use inputenc, or use the [utf8] option.

On version 1.16.0 from TeX Live distribution version 2023 using LUALaTeX 2023.8.28. It appears when `\usepackage{babel}` is modified to `\usepackage[arabic]{babel}`

>From what I understand LUATeX use by default UTF-8 and using inputenc will conflict with it because it tries to re-define the encoding which is locked in LUA/Xe, so will end up in a "crash". So Babel (or whatever invoke it) shouldn't do it (I think it tries to use cp1256 here, despite not asking for it) when not using PDFTeX (or whatever needs it), like on that case. And worse, some calls takes priority so re-using inputenc to ask for UTF-8 won't correct the problem because it takes the first call only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20240605/c3529aa1/attachment.htm>