# Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2458 - Localized TeX environment
 Summary: Localized TeX environment
 Status: Product: REOPENED MediaWiki extensions Unclassified Component: Math (Other open bugs) unspecified All All Low normal --- physikerwelt 798 38721 Show dependency tree / graph

 Reported: 2005-06-19 14:33 UTC by Maxim Razin 2013-11-02 13:35 UTC (History) 7 users (show) dmharvey gangleri jutiphan meno25mail peter.krautzberger philippe.gauthier physik --- --- ---

Attachments

 Maxim Razin 2005-06-19 14:33:18 UTC Many aspects of TeX rendering depend on local traditions. The most essential are: * National characters in formulae and indices cannot be entered. * The [[:en:decimal separator]] is a comma in many countries (ru, fr, de and others). TeX by default treats a comma as a list separator, adding a very large skip after in: compare $3.14\,\!$ and $3,14\,\!$. Actually, we can write $3{,}14$ but it's a dirty hack. * Some functions have national variants of designation, for example, '''tg''' instead of '''tan'''. To avoid clumsy \mathop construction, we need a method for entering such names. A reasonable way for fighting with all these inconveniences is to allow national versions having their own TeX macros in preamble. There exists "babel" in LaTeX, why not in texvc? Ævar Arnfjörð Bjarmason 2005-06-19 14:43:21 UTC (In reply to comment #0) > * National characters in formulae and indices cannot be entered. Please confirm that this is indeed the case, the math package supports that if you configure it correctly, but it hasn't been setup like that on Wikimedia sites. And please submit bugs that describe one and only one issue, full UTF-8 support in the math pagkage and some kind of template support are totally different issues, marking this as INVALID,  Maxim Razin 2005-06-19 20:52:50 UTC It is a bug of the wikipedia.org installation and possible other installations which pretend to support more than one language. Converting to UTF-8 does not resolve all localization problems, even if the TeX engine will be moved to a fully-unicode version (Omega?). The point is not to try fitting all possible localization problems in one basket but to put language-dependant things in language-dependant places. Maxim Razin 2005-06-21 06:06:36 UTC It depends on bug 798, but is not the same Fibonacci 2006-01-16 09:12:42 UTC Example: the Spanish word for "limit" is "límite", which is abbreviated "lím". There is no way to write this with the current Texvc implementation - \acute{i} is not rendered as í, but as an acute accent over an 'i' with a dot. Besides, $\lim_{x\to0}\frac{\sin(x)}{x}$ is correctly rendered with the $x\to0$ part under the "lim", while $\mbox{l}\mbox{\acute{i}}\mbox{m}_{x\to0}\frac{\sin(x)}{x}$ is not, and it looks awful. I know from experience that loading the "babel" package with the appropriate option solves almost all of the problems, at least in Spanish, and probably for the other languages too. Alon Lischinsky 2006-01-18 20:10:41 UTC (In reply to comment #1) > And please submit bugs that describe one and only one issue, full UTF-8 support > in the math pagkage and some kind of template support are totally different > issues, marking this as INVALID, It's likely that this describes one and only one issue. The bug may not be in Unicode parsing, but in misinterpretation by texvc of non-ASCII characters, which is in all likelihood triggered by lack of locale support. The later is usually ensured by the babel LaTeX package, which also localizes abbreviations for mathematical functions. Tomasz Wegrzanowski 2006-02-07 18:16:17 UTC I would strongly advise against using different setups on different Wikipedias. This is simply asking for all kinds of weird problems. If you need \tg etc., just add it to texvc as alias for \mathop{tg}, something like that in the big case statement in texutil.ml: | "\\tg" -> LITERAL (HTMLABLEC(FONT_UFH,"\\mathop{tg} ","tg")) The tests seemed to indicate that one cannot write accented characters directly in math mode, so I'm not sure how you want to get \mathop{lím} there.  Alon Lischinsky 2006-02-07 18:24:26 UTC Why should localization of texvc through the use of a well-tested and widely-used LaTeX package cause "weird problems"? Fibonacci 2006-02-07 18:59:34 UTC (In reply to comment #6) > I would strongly advise against using different setups on different Wikipedias. > This is simply asking for all kinds of weird problems. Echo Alon Lischinsky. > If you need \tg etc., just add it to texvc as alias for \mathop{tg}, > something like that in the big case statement in texutil.ml: > | "\\tg" -> LITERAL (HTMLABLEC(FONT_UFH,"\\mathop{tg} ","tg")) And how, exactly, do I "just add it"? > The tests seemed to indicate that one cannot write accented characters directly > in math mode, so I'm not sure how you want to get \mathop{lím} there. However it can be done. I don't really care how, as long as it works. Rob Church 2006-02-07 19:06:36 UTC Alright, let's keep the priorities sensible. And drop the attitudes, please. Thanks. Carlos Eugenio Thompson Pinzón 2006-02-08 00:47:08 UTC (In reply to comment #6) > I would strongly advise against using different setups on different Wikipedias. > This is simply asking for all kinds of weird problems. Well, Wikimedia Foundation charter states that Wikimedia is a multilanguage project, so localization of resources is something MediaWiki should attempt to do, IMO. babel package is supposed to work with both LaTeX and Plain-TeX, so we have a tested package as a tool. I would like to hear a technical, rather than a political opinion, for why babel (or any other type of regionalization) is not practical or feasible for WikiMedia's texvc implementation. Brion Vibber 2006-02-08 01:54:38 UTC If the same source renders differently on each wiki, it'll complicate the shared storage of rendered images. More generally, a multilingual solution rather than monolingual is preferred, so all languages can be used on all sites. Fibonacci 2006-02-08 02:15:33 UTC (In reply to comment #11) > More generally, a multilingual solution rather than > monolingual is preferred, so all languages can be used on all sites. But while such a solution is found, it would be better to use babel instead of waiting. Back in the days where article titles in the English WP could only use letters from Latin-1, WPs in languages whose alphabet wasn't included in Latin-1 (such as Polish or Esperanto) were allowed to name their articles in their own character encoding (or was it Unicode? I don't remember), instead of waiting for a multilingual solution to be implemented on all the WikiMedia projects. Well, why not do the same here? Brion Vibber 2006-02-08 02:31:16 UTC Please stop manipulating the priority tags; it doesn't do you any good and just annoys people, making it less likely anyone will want to do whatever you are asking for. Carlos Eugenio Thompson Pinzón 2006-02-08 14:57:41 UTC (In reply to comment #11) > If the same source renders differently on each wiki, it'll complicate the shared > storage of rendered images. More generally, a multilingual solution rather than > monolingual is preferred, so all languages can be used on all sites. But, anyhow, mathematical convensions are different in different languages, so it is likely that either the formulas use different sources (some with workarounds) which make the argument of shared storage void, or just share the source making the article/book look like a shiftcoded work. This is, IMO, still a political rather than a technical argument: you are not saying it is imposible/too complicated/prone to unseen failures, but rather that this is inconvenient from the point of view of shared resources, when shared resources are, in this context, either something that is not happening or an imposition of language convensions. Brion Vibber 2006-02-08 22:40:43 UTC No, it's a technical argument. If simply turned on, this would cause different renderings to stomp on each other and make rendered display inconsistent. Alon Lischinsky 2006-02-09 15:05:31 UTC (In reply to comment #15) > No, it's a technical argument. If simply turned on, this would cause different > renderings to stomp on each other and make rendered display inconsistent. Not inconsistent, but rather consistent with the language setting for the local wiki (or, if it could be implemented, for the user viewing the page). You're placing technical ease-of-maintenance (or worse, technical resource optimization) above usability, a flawed line of reasoning which, if pursued, could lead to producing an extremely efficient product that doesn't fulfill the users' needs. I don't see why non-English speakers shoudl be forced to employ English, a language they may not even understand, for their formulae. Brion Vibber 2006-02-09 18:32:43 UTC No, *inconsistent* because it would change back and forth depending on who rendered it last. Alon Lischinsky 2006-02-10 14:32:58 UTC (In reply to comment #17) > No, *inconsistent* because it would change back and forth depending on who > rendered it last. Only if PNG caching is done independently of user language setting. Which need not be the case: just like thumbnailed images are rendered as per the user's thumbnail size setting selection, LaTeX rendering can be linked to interface language. And it should, unless your particular criterion is, as I said before, that technical optimization should not take end-user satisfaction into account. Fibonacci 2006-10-30 05:26:21 UTC Why was this tagged as fixed? I've just checked, and \lim renders without an accent on es:. Jutiphan 2006-12-19 10:20:14 UTC This is quite an important bug since it affects all other languages (that just do not use English characters) These problems have been so long standing and seems no one bother to fix them. It would be great if globalization is being paid attention to. This issue particularly affects Thai wikipedia and is having problems writing equations with words in it.  physikerwelt 2013-10-22 19:46:06 UTC did you try to use \text if you want to insert text or other symbols that have no specific math rendering. I think it makes little sense to support characters that are not supported by LaTeX since it's not defined how they look like. So I'd recommend to use \text{special words characters or symbols} to get the browsers rendering for those parts of the equation. There are some cases were the text method does not work. If you discover such situations that are not covered by https://bugzilla.wikimedia.org/show_bug.cgi?id=48032 Please open a new bug with a specific example. *** This bug has been marked as a duplicate of bug 48032 *** Peter Krautzberger 2013-10-22 20:42:05 UTC Moritz, I don't think this is a duplicate. In TeX/LaTeX terms, this is about the babel package. E.g., babel set to Spanish will render \lim, \max, min etc. as lím, máx, mín etc. At least for MathJax, this can be solved by simply writing sets of macros. (Not sure how the math extension / database side would work.) physikerwelt 2013-10-22 21:10:50 UTC Peter, thanks for the hint. Obviously, I misunderstood that. I would see that as new feature for one version in the future. Hopefully (Repopend) is the right category for that. I also added it to the Roadmap. https://www.mediawiki.org/wiki/Extension:Math/Roadmap It's also a nice example to demonstrate the usefulness of Content MathML. Jutiphan 2013-11-02 13:35:43 UTC Physikerwelt, Thank you for looking into this. It's been long 7 years coming that I actually have forgotten about it.

 Note You need to log in before you can comment on or make changes to this bug.