When having \setotherlanguage{hebrew} active, then even in an english environment it reverses the order of words in a \text{} for a math environment.
Here is a minimal working example of this behaviour.
\documentclass{minimal}
\usepackage[T1]{fontenc}
\usepackage{amsmath}
\usepackage{polyglossi...
@ArthurReutenauer The problem is that \if@Latin is never set to true. I guess it should be called \if@LTR and that left-to-right languages should set it to true and right-to-left ones to false. Where this should be done is a more general question: how to persuade Vafa to cooperate?
@egreg Your guess is as good as mine. The other day he blamed me for not fixing issues he filed with Polyglossia, that would be best addressed in bidi. I actually have no idea what to do about this kind of situations.
@egreg I was going to say something sarcastic, but I gave up. There’s not enough time in the world to spend on that, and I don’t have it in me to pursue it with the same kind of caustic energy he puts into it.
@egreg You’ll note that the bugs were originally reported by an account that has now been deleted (“ghost”) – that was him too of course. Even if he wasn’t temperamental it would be very hard to make any real progress on these issues since he never follows up on his own requests.
@JosephWright Sure :-) Not sure if I’ll be able to answer them, but well ...
@ArthurReutenauer The hyphenation patterns for plain and LaTeX2e are set up using the babel interface. There's a comment somewhere saying ConTeXt has it's own language interface. Does it use the same patterns as plain/2e, and if so does it use the same language ID values (and how are they kept in sync)?
@JosephWright Oh, this I know the answers too :-) Unfortunately ...
ConTeXt uses a copy of the patterns for hyph-utf8 with its own language codes that are specific to ConTeXt – basically, using whatever codes Hans decided to use when he was adding languages.
They’re kept in sync by Hans, I don’t know how often and exactly how he does it.
@ArthurReutenauer Reason for question: I'm wondering about pattern loading for LaTeX3. The current hyph-utf8 stuff is probably not directly suitable but obviously the patterns themselves are. I was hoping there might heave been a 'name = number' mapping used by plain, LaTeX2 and ConTeXt to construct the relevant loaders. Seems I'll have to roll my own.
@JosephWright I don’t think I’m unfair to Hans when I say that he has no interest in established standards and will never follow them just for the sake of following standards.
@ArthurReutenauer That sounds about right [see upcoming LuaTeX changes, for example :-)]
@ArthurReutenauer I was thinking more that it would not have been too complex to write a simple file with the number mapping and then script from that to the loaders such that the numbers would always be the same across all formats, even if the loaders themselves vary.
@ArthurReutenauer I guess my current plan is to do something like Hans then, except keeping the order strictly the same as 2e
@ArthurReutenauer clearly "whatever codes Hans decided" is a suboptimal policy compared with the new clearly more functional LaTeX3 policy of "whatever codes Joseph decided"
@JosephWright But he’s sensitive to the need for interoperability and stability. The only real question is where to set the bar for backward compatibility. Hans is a pragmatist, to sum up.
@JosephWright Wait, what numbers do you mean? I had thought the numbers in the \language register, but that can’t be what you mean since that depends on language.dat
@JosephWright No, but neither does LaTeX. These numbers are based on the order in which the languages are defined in language.dat and are completely configurable.
@JosephWright It does, indirectly. The actual numbers are assigned by hyphen.cfg that comes with Babel, and essentially does it sequentially.
@JosephWright the original idea of language.dat was that it was a site configuration and the numbers would vary (of course since tex is big enough usually to simply load all the languages I guess it's more standardised now, but relying on the numbers would be bad wouldn't it?
@JosephWright Of course not. language.dat is ultimately under the control of the user (via some configuration mechanism in TeX Live); it’s usually ordered alphabetically with the exception that english, pointing to hyphen.tex, has to always be first by policy.
@JosephWright So you can’t rely on anything, except that \language0 will be “english” and will use the file hyphen.tex by Knuth et al.
@JosephWright That’s the wrong way to look at it. The identifier is the alphabetical string; the numbers are just a convenience for TeX to use the \language primitive.
@JosephWright but \language are allocated like boxes \newlanguage just associates the next free slot, you are not supposed to care (or rely) on what slot that is.
@JosephWright If you wanted to overhaul hyphen.cfg that would certainly be welcome; I suppose that formally it’s under the responsibility or Javier, but I don’t think he has any plan for it.
@JosephWright We’ve never done that and I don’t think that’s the way to go. I’m not aware of any project that actually numbers language (other than as an expedient).
@DavidCarlisle, @ArthurReutenauer Anyway, what I was originally wondering was whether for the same TeX system if ConTeXt followed the same allocation as LaTeX2e/plain
@JosephWright there could in principle be more than 256 patterns , so having a fixed number would be bad as you have to choose an arbitrary subset of them and number that 0-255
@JosephWright But remembers that “languages” at this level are just sets of hyphenation patterns; they’re not mapped to actual languages (whatever that could be) and they actually make even less sense than other registers, potentially.
@ArthurReutenauer, @DavidCarlisle Probably I can arrange to parse language.dat to get to where I think I want to (it's mainly a question of picking up the language name and the identifier stub, then handling a few special cases)
@ArthurReutenauer 1) Detect engine based on the fact we have an engine test rather than some heuristics 2) Allow for the fact that LaTeX3 as a format moves all of the primitives out of the way 3) Allow for the fact probably only T1 and UTF-8 will be allowed
@ArthurReutenauer 4) Allow for the fact that it's possible that LaTeX3 won't search the generic tree (as the primitives get moved)
@ArthurReutenauer All 'up in the air' but I'm exploring things
@DavidCarlisle Doubtless has a view ('oh no, he's at it again' or something)
@JosephWright I was writing something similar but deleted as I'd guessed you were writing:-) Not requiring the 2e codebase for the latex3 format mode implies not using babel so you have to do something more or less new to load the patterns. (even if it ends up being the same except with _ and : added to command names.)
@JosephWright What @DavidCarlisle said. You are saying, between the lines, that you want to reimplement the relevant parts of hyphen.cfg
@JosephWright I’m happy to continue some other time as I’ve had issues with hyphen.cfg myself (when porting Polyglossia to LuaTeX, for example), but I really need to get back to work now.
@DavidCarlisle The bit 'inside' language.dat is slightly different as it's not exactly tied to babel (beyond the need to read the file and 'do stuff'). I'm thinking mainly at the moment about all of the stuff related to different encodings (which we might reasonably want to rationalise/drop/....). @ArthurReutenauer's info is useful: I have some idea now of how Hans tackles this.
@ArthurReutenauer The key point is that you'd know if the mechanisms you are involved in had been modified or where fixed in some way to work with ConTeXt, so I can assume Hans does his own thing
The settings in beamer for japanese language providing are too complicated, same as any oter class for slides which is not adapted for japanese. I find some TeX-based class, application, or package for slides creating which comfortable if use japanese.
For now, I use japanese-language classes in...
@michal.h21 Should be possible to do a lookup to the language name, I'd imagine (if nothing else one could alter \newlanguage to store the data in a Lua table)
@michal.h21 I'm mainly worried about plain/2e/ConTeXt cross-compatibility
@JosephWright Any thoughts on what to do with the japanese Slides question i linked above? It has an open bounty ending soon and the last comment confuses me a bit
@Johannes_B Mod power: we are meant to use it sparingly (as giving a bounty gets extra views, which the rep 'pays' for)
@ArthurReutenauer Probably :-) I suspect this should be doable 'directly', as for other registers, but that is in reality at present a bit hit-and-miss (see weird artefacts based on exact naming of commands, etc.)
@ArthurReutenauer What's the reason for having the hyph-<id>.pat.txt files? They look very much like the content of \patterns but without the TeX part.
@ArthurReutenauer Looks like you might have saved me one job :-) The combination hyph-<id>.hyh.txt and hyph-<id>.pat.txt does what we probably want (provides the raw data) without needing to rename (again) the primitives :-)
@JosephWright Yes, that is the point. They’re used by other projects – not directly unfortunately, but since the format is the same in all free software that deals with hyphenation we tried to set up a collaboration with them. They were picked up by OpenOffice / LibreOffice, an XML-FO parser called OFFO, Firefox, and other projects I forget.
@ArthurReutenauer Ah, that was going to be one question: I have to look up how to do \patterns for LuaTeX (I know they are different from TeX90 but not the detail)
@michal.h21 As I reminded Joseph above, the values of \language depend on the installation and can be anything. They’re not portable and shouldn’t be stored.
@michal.h21 Yes, of course, you can use auxiliary functions to read its value. But you shouldn’t store it. And no, it’s absolutely not portable. But that doesn’t prevent implementations from using the numbers internally.
@michal.h21 The programming interface of luatex-hyphen is rather poor anyway and should be rethought at some point, looking at actual implementations.
@JosephWright: How does \RenewDocumentEnvironment work for an environment foo that should be extended to allow for \begin{foo*}`? (and had no starred version before )
@ChristianHupfer For environments, there is no connection between foo and foo*. In this sense, they are very diffirent from macros. Note also that foo * and foo* environments are different, whereas for macros, \foo * and \foo* are interchangable.
@ChristianHupfer well \begin{..} is \begingroup\csname#1\endcsname so actually although not widely documented you can do \newenvironment{funky name with * and +}{zzz}{zzz}\begin{funky name with * and +}