Template talk:Transliteration/Archive 1

This is an archive of past discussions about Template:Transliteration. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Documentation

If this page is fully protected, it should probably use the Template doc page pattern. Cheers. --MZMcBride 16:09, 15 April 2007 (UTC)

good point. dab (𒁳) 16:17, 15 April 2007 (UTC)

Unification

the template should ultimately be unified with {{lang}}: It should amount to identical results whether you say {{transl|xx|...}} or {{lang|xx-Latn|...}}. But this will have to wait until we get a clearer picture of what is required in terms of disambiguation of various cases in the css file. At present, we are setting class="unicode" (formerly "latinx") regardless of which language is being transliterated. This is a progress over various ad-hoc classes we used to have ("IAST", "Arabic Unicode", ...). If it would be possible to tell the browser "if the 'lang' parameter contains '-Latn', use class 'unicode'", we would be done, but an exhaustive list of ":lang(xx-Latn)" pseudo-classes would clutter the css file too much. The best solution may be to just wait for another half year, and then try to silently transclude {{lang}}, hoping that soon the vast majority of browsers out there will not have problems rendering the Latin Extended range even without being told "class='unicode'". dab (𒁳) 13:31, 19 April 2007 (UTC)

Hello dab, I think this template for transliterations (well, really for romanizations) is a great idea! I used to employ the {{lang}} template with the "Latn" script code for transliterations, but now I will use your template because in many cases there are more than one possible translations. But I not sure if this template should be merged with lang (adding some optional parameters to indicate the transliteration scheme). However, I have some ideas to add a simple transliteration capability to the lang template, see Template talk:Lang#Overspecifying and Template talk:Lang-ru test. Anyway, I do believe there are far too many multilanguage templates, and we should unify them. Best regards —surueña 12:33, 21 July 2007 (UTC)

yes -- the many legacy language templates reflect formatting problems of common browsers in the early 2000s, and the immediate need of using them will die off with better out-of-the-box rendering capabilities of, let's face it, M$IE. It is a good idea to unify them gently. As I state in the usage notes, this template should ultimately also be a shortcut to {{lang}}, inserting a "-Latn" string. dab (𒁳) 17:15, 22 July 2007 (UTC)

OK, I see your point now. I though your idea was to merge this template with lang (adding optional arguments), so editors only have to use one template for non-English words, but you are saying that the transl template should use internally the lang one, isn't? From my POV that's fine, but I think that editors should employ both templates for different usages, and so they shouldn't be ultimatelly merged: {{lang}} for foreign words, and {{transl}} for transliterations of those non-English words (there are languages using multiple scripts, including Latin characters). But I think it is very important to note that these templates are not only to resolve current browser issues, but to provide semantic info that can be computer processed. In the future, even if browsers don't have any presentation problems, the language code and the transliteration scheme should also be specified (that's the reason I think {{script}} is not a good approach, because it doesn't provide the language info), but I'm sure you have read the rationale at the Template talk:Lang documentation. Best regards —surueña 19:00, 22 July 2007 (UTC)

you misunderstand.

the various obsolete templates were created because of rendering issues.
this template should (ultimately) redirect to lang in the sense that {{transl|ar|...}} and {{lang|ar-Latn|...}} are equivalent. "ar-Latn" already means "romanization".
{{script}} is for cases where the script itself is under discussion
your point about semantic info is well taken, but that can all be done with a single template, {{lang}}.

dab (𒁳) 19:13, 22 July 2007 (UTC)

Yes, but now I understands correctly your point. "ar-Latn" means "romanization", but this is not always the case. Tajik language uses indistintively the Cyrillic, Latin and Arabic scripts, so in some cases "tg-Latn" would refer to an actual Tajik word in the Latin alphabet, or to a romanization of a word in Cyrillic or Arabic (are not the same, see Tajik alphabet#Tajik Latin, Tajik Cyrillic, and Perso-Arabic). Thus the lang template cannot provide enough semantic info for transliterations. In addition to the case of Tajik, there are usually more than one transliteration scheme for each language, so Latn is not enough and private language code must be created. For that reason, these transliteration codes shouldn't be directly inserted by editors using the lang template, but by the transl one. Best regards —surueña 21:47, 22 July 2007 (UTC)

of course not. One of the reasons I have created this template is precisely the possibility to specify romanization schemes. I have also documented this in Template:Transl/doc. dab (𒁳) 07:07, 23 July 2007 (UTC)

{{{{PAGENAME}}/doc}} change to {{Documentation}}

{{editprotected}} Please change {{{{PAGENAME}}/doc}} to {{Documentation}} so that it notes that it is transcluded. Direct transclusion, even if marked with <noinclude> tags, is not clear as to whether it is part of the template or not. --Geopgeop (T) 07:30, 21 February 2008 (UTC) Done. עוד מישהו Od Mishehu 10:39, 21 February 2008 (UTC)

Font for translated words

Why is the font for translated words different from the rest of the text? It makes the page look really ugly. At least, it is rendered differently in firefox. In IE it appears to be the same font. Please see Go (boardgame) for an example. --- SuperMidget (talk) 11:37, 10 March 2008 (UTC)

I don't know why, but I guess it has something to do with stylesheets. Compare

Qwertyuiop: Qwertyuiop (a Times font in Firefox)

Qwertyuiop: Qwertyuiop (a sanserif font in Firefox, but not the usual one)

Qwertyuiop: Qwertyuiop (a condensed sanserif font in Firefox)

I agree it looks ugly. --Lambiam 16:09, 9 July 2008 (UTC)

I get different results. ar-Latn and ru-Latn give me Arial in Firefox, although my standard sans serif font is Verdana. el-Latn gives me a serif font, but that's probably because of my personal css settings. —An gr 09:29, 20 September 2008 (UTC)

This needs to by addressed in the stylesheet, MediaWiki:Common.css.

I think the problem is that your browser only looks at "ar" and ignores the "-Latn". This is strictly speaking a browser bug: the browser should pick the font based on the script used, not on the language encoded by the script, but I can imagine that an "ar" tag normally means that Arabic script follows. Redundantly, because Arabic script can be recognized as such even without any tags (that is, I do not believe browsers should pick any fonts based on language tags). But it can probably be fixed by explicitly introducing an "ar-Latn" pseudo-class at MediaWiki:Common.css. Or maybe there is a smarter solution, this would be something for the tech-savvy to be worked out, at MediaWiki_talk:Common.css. --dab (𒁳) 11:09, 20 September 2008 (UTC)

Arabic not visible

Why is the Arabic in the first line of Muhammad ibn Mūsā al-Khwārizmī not showing up (although visible when editing)? Badagnani (talk) 19:55, 23 March 2008 (UTC)

this is an issue with your browser, or your system fonts. The problem is at your end :) --dab (𒁳) 11:05, 20 September 2008 (UTC)

No, it is not. The HTML generated by Wikipedia for the passage reads

...Abū ʿAbdallāh Muḥammad ibn Mūsā al-Khwārizmī<a href="#cite_note-0">[1]</a> ...

The original Arabic text is simply not there, so the browser has no chance of mishandling it. On the other hand, there is no evidence that the template is supposed to support two parameters like that. — Emil J. 16:41, 25 January 2010 (UTC)

Needless

I think the problem is that your browser...

Is not the problem. The ugly template is. And it's real ugly. And it's completely needless. There is nothing this template does that isn't better dealt with via four apostrophes italicizing the transliteration.

If the lang template can include the transliteration as a field, great, why not; but this template should be mothballed and edited or scripted off of pages. -LlywelynII (talk) 19:21, 6 October 2010 (UTC)

Other transliterations

What is the correct way to use this with other transliteration schemes? Case in question, some editor adding ALFB NewWay transliterations to articles. --Muhandes (talk) 09:20, 21 January 2011 (UTC)

DIN parameter

If the DIN option to "ar" (Arabic) is mainly being used to sneak in Egyptian pronunciation preferences, as opposed to the most widely used practices of transliterating Arabic into English (see User_talk:Mahmudmasri#ǧ_for_ج), then it should probably be removed... AnonMoos (talk) 14:59, 2 March 2011 (UTC)

Matching Arabic plural with English plural

Since the word شيعة is plural, as the article rightly points out, it would be proper to give the English translations of the term in the plural as well. After all, what sense would it make to translate مدارس as 'school' or بيت as 'houses?' I therefore respectfully request that the English text of the Translation template be modified to read 'followers/partisans.' Thank you. —Preceding unsigned comment added by Rafa8134 (talk • contribs) 07:17, 23 May 2011 (UTC)

Are you sure this has anything to do with the {{transl}} template? What article would you like to change? --Muhandes (talk) 11:04, 23 May 2011 (UTC)

Do we need the lang in the markup?

See the section above, #Font for translated words. Including a language like ar-Latn or sa-Latn results in strange output, because of a browser bug. Since it is not within our power to fix the browser bug, how about simply removing the lang markup (or setting it to English/Latin) in the template? This was suggested at MediaWiki talk:Common.css#Get lang sa-latn to display in normal font. Shreevatsa (talk) 19:55, 30 July 2010 (UTC)

No, they don't do anything at all, other than adding "context" for machines most likely. 82.75.135.94 (talk) 20:56, 30 July 2010 (UTC)

The "browser bug" is supposed to be a feature, we are enabling browsers to pick fonts depending on the language. I really think it would be a step backward to remove this possibility. The tag adds meta-information, it doesn't pick a font, I believe this should be fixed at the css level. --dab (𒁳) 22:48, 30 July 2010 (UTC)

I know, and ideally the browser would understand which language it is and pick the right one... but it seems to be getting it wrong. If we removed the lang attribute, the template would still have 'xml:lang="ar-Latn"' (etc.) as it does now; do you know if that might suffice as metadata? I've asked both on the CSS page and here, and both places want it to be fixed at the other. :-) (I also feel it's better to fix with CSS.) Shreevatsa (talk) 23:42, 30 July 2010 (UTC)

You have a point, the xml:lang tag will still be there. As far as I can see, the lang tag currently doesn't do anything crucial, I think this was something mostly intended for "future use". Although I can imagine that voice synthesizers for the blind rely on it for proper pronunciation. Also, enforcing standards on Wikipedia can be a powerful incentive for browser developers to fix their bugs ("Wikipedia is broken" boosts bug priorities more than "there is some obscure standard which we are violating").

If you like, we can remove the "lang" tag from the live template for the time being. We can experiment in a sandbox if we can find a satisfactory css solution. But in the near future I probably won't be able to invest time in this. --dab (𒁳) 08:13, 31 July 2010 (UTC)

I have removed the lang tags. They simply were causing too many problems, for too little benifits in the case of transliterations. —TheDJ (talk • contribs) 19:13, 5 August 2010 (UTC)

Mozilla has stated that they will implement this is now on their todo schedule. https://bugzilla.mozilla.org/show_bug.cgi?id=192636 https://wiki.mozilla.org/User:GPHemsley/BCP_47 https://bugzilla.mozilla.org/show_bug.cgi?id=356038 —TheDJ (talk • contribs) 20:25, 23 June 2011 (UTC)

Also interesting, a specific proposal for transliteration tags. Goes even further than flipping the 'script' tag that we were doing here (and which technically isn't really allowed within BCP 47). —TheDJ (talk • contribs) 08:14, 28 June 2011 (UTC)

Example: ru-Latn-s-Cyrl-t-iso9 :: language-script-s-sourcescript-t-transliterationsystem. with the s- and t- being indicator prefixes for sourcescript and transliteration system. —TheDJ (talk • contribs) 08:18, 28 June 2011 (UTC)

Minor URL fix in comment

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please change the URL of the diff, in the comment at the head of the template, to that for the full, archived conversation:

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_12#Get_lang_sa-latn_to_display_in_normal_font

Thank you. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 12:32, 1 November 2011 (UTC)

I have moved the comment to the edit notice and made the change you requested. Hope this is okay. — Martin (MSGJ · talk) 11:55, 2 November 2011 (UTC)

Fine by me. Thank you. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 19:38, 7 November 2011 (UTC)

Edit request on 8 January 2012

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Tajiki (tg) is written with Cyrillic.

--Z 18:47, 8 January 2012 (UTC)

I'm sorry, what do you want done? I'm not sure I understand. Killiondude (talk) 05:53, 21 January 2012 (UTC)

See this diff. --Z 09:55, 21 January 2012 (UTC)

Done Skier Dude (talk) 02:26, 22 January 2012 (UTC)

This template is useless

With the removal of lang/xml:lang, all this template does is add a title attribute with the name of the translit scheme used (sometimes); and no help cursor, no dotted underline, no nothing, and no screen reader support and no support for mobile. I think it should be made to have the kind of translit used in text, wikilinked, before the translit itself and the translit lang-tagged again. If this is not desirable, we should just nuke it. — Lfdder (talk) 09:58, 6 September 2013 (UTC)

Taking to TfD where more people will see it. — Lfdder (talk) 10:01, 6 September 2013 (UTC)

Edit request on 6 September 2013

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add {{subst:tfd|type=tiny}} to the top...if necessary. — Lfdder (talk) 22:22, 6 September 2013 (UTC)

Done --Redrose64 (talk) 23:01, 6 September 2013 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can this be undone? Type=inline is too obtrusive and the discussion was started on the 6th. — Lfdder (talk) 00:14, 7 September 2013 (UTC)

Please, don't delete this template.... I want to see the translation..... — Preceding unsigned comment added by YogaWP (talk • contribs) 09:07, 8 September 2013 (UTC)

Please discuss at Wikipedia:Templates for discussion/Log/2013 September 6#Template:Transl, not here. --Redrose64 (talk) 20:23, 8 September 2013 (UTC)

Edit request on 9 September 2013

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Put the Tfd notice inside noincludes. It's breaking links and it's a fucking eyesore to look at. — Lfdder (talk) 09:00, 9 September 2013 (UTC)

Done --Redrose64 (talk) 13:01, 9 September 2013 (UTC)

Revisiting -Latn

Moved from MediaWiki talk:Common.css § Getting rid of giant CJK text in Latin script

This decision may need to be revisited, since several years have passed. The rationale no longer seems to hold, though I've not broken out my entire batch of virtual machines, just tested a bunch so far: http://www.well.com/user/mech/temp/WP/xx-Latn_test.html

It works as expected in Crome/Chromium/ChromeOS, Safari, Konqueror, Explorer (in tests so far), Lynx, and usually in Firefox; in some Firefox installs, it had some minor issues, but they should be resolvable to the extent they matter. Details so far are included at the bottom of the test page. What should happen is that a browser that doesn't do anything with the value given just ignores it, and this seems to be the case for everything except two Firefox cases I've found so far (one futzes a bit with line height, the other soemtimes uses serif instead of sans-serif, but these should be fixable with inherit. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:29, 9 September 2015 (UTC)

Yes firefox specically was what people were complaining about back then as well. —TheDJ (talk • contribs) 13:07, 9 September 2015 (UTC)

If the display issues with FF are minor enough, we don't necessarily need to care. It's not WP/WMF's job to work around third-party developers' coding mistakes. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:46, 10 September 2015 (UTC)

Oh and of note is that -Latn isn't the only script. I remember that the issues with other script extensions were significantly worse. —TheDJ (talk • contribs) 13:08, 9 September 2015 (UTC)

That could be, but it looks to me like no one around these-here parts has looked into the matter in some years. I've been doing some digging, and it's hard to figure out where this stuff is really coming from. There's a list of language subtags assigned by IANA (seems to be updated, as it has 2015 entries; takes a while to figure out how to read): http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry (by why IANA is doing this I don't know; seems more like ISO territory to me). This list used to be updated via a form submission process at http://www.iana.org/assignments/language-tags/language-tags.xhtml but this is now prominently labeled "OBSOLETE ... Last Updated 2010-06-17", but refers to the same "language-subtag-registry"; this seems to indicate that the registry is current, but the submission process has changed, in a "crypto-documented" manner. The "OBSOLETE" page refers to [RFC4646], and the earlier [BCP47], [RFC3066], and perhaps one of these will indicate what has superseded it since 2010. From what I can find so far, it simply is not clear how subtags are getting into and being removed from language-subtag-registry in 2015.

Weirdly, it still does not have ja-Latn or zh-Latn (or something more specific like ja-Hepburn), despite standardized (even governmentally officialized) Latin-alphabet transliteration systems for them have existed for generations. I'm not really sure what to make of that. I'm pretty sure that we shouldn't be failing to mark up transliterated Japanese in some way, and that we should not be presenting it as English. As a site I ran into yesterday observed, this is an accessibility problem as well as a usability one, since it will affect how screen readers attempt to pronounce things ([arigato] Error: {{Lang}}: text has italic markup (help) in Japanese sounds nothing like what people familiar with an English song like "Mr. Roboto" think it does, which is probably pretty close to how an English-weighted screen reader would handle it).

Anyway, the language-subtag-registry gives plenty of fodder for building a table of test strings for each subtag and seeing what breaks when you render it in various browsers. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 10:41, 10 September 2015 (UTC)

Not working with script codes

According to the documentation, this template should also work with ISO 15924 script codes, for example {{transl|Cyrl|š}}. That doesn't seem to be working now. Instead, the script code is taken to be an ISO 639 language code and the template from the example transcludes to the non-existing {{ISO 639 name Cyrl}}.Uanfala (talk) 19:17, 25 December 2015 (UTC)

I'm seeing the same thing, for example in Bat hawk:

"The genus name is from Greek: μαχαιρα makhaira meaning knife; and ῥαμφος rhamphos, bill.

The above excerpt calls Template:ISO 639 name Grek, which is incorrect, since "Grek" is not an ISO 639 code. – Jonesey95 (talk) 06:38, 16 October 2016 (UTC)

Category:Articles containing Semitic languages-language text

It appears that Template:Transl/Template:Lang is the common denominator between the articles in Category:Articles containing Semitic languages-language text rather than Category:Articles containing other Semitic-language text. In Aleph "sem" is only a variable in the Template:Transl but in Adnan, "sem-Latn" is called in Template:Lang. Hyacinth (talk) 22:12, 1 December 2017 (UTC) Hyacinth (talk) 22:19, 1 December 2017 (UTC)

Template:ISO 639 name sem may contain a problem. Hyacinth (talk) 22:35, 1 December 2017 (UTC)

Sukkot is showing a template error...

Not quite sure what's wrong. Maybe the macron'd o? Adam Cuerden ^(talk) 13:48, 24 December 2017 (UTC)

It just needed a null edit to reload a template that had a bug and then was fixed. – Jonesey95 (talk) 15:02, 24 December 2017 (UTC)

rewriting this template?

Many of the old wiki-text versions of the {{lang-??}} templates called this template. When I wrote Module:lang to be the centralized engine for all of those templates, I added support there for handling transliterations. As a result, only a few, if any, of the {{lang-??}} templates that have not yet been converted to use Module:lang call this template. That leaves standalone calls from article space and some 150-ish calls from template space.

I've been wondering if we shouldn't change this template to use the same base code as is used by the {{lang-??}} templates. As an experiment I have added a function to Module:lang/sandbox, transl(). This first hack module version, for the most part, gets it right. See Template:transl/testcases.

The most obvious differences are italic rendering; transliterations at en.wiki use Latn script so should be italicized; the error noted at §Not working with script codes is not present.

I wonder about italics though. When given an ISO 15924 script code, should the text necessarily be italicized? For example, should a single Cyrillic character (code parameter {{{1}}} set to cyrl) be rendered as 'š' or as 'š'?

Were there a wishlist for how this template might be improved, what would be on that list?

—Trappist the monk (talk) 17:04, 4 January 2018 (UTC)

If the template could do the transliteration by itself if supplied with a string in a foreign script, that would be great – I know that's a long shot and I don't expect this to ever happen (though there are templates that do that for Greek and for Georgian). More realistically, there's one aspect of this template's behaviour that I would like to see changed: currently, if a transliteration scheme isn't specified by the user, it makes an assumption. This is not safe: people use all sorts of transliteration schemes and variants without specifying them and we shouldn't simply assume that, say, the scheme is ISO 9 Cyrillic just because the text is in Belarusian. However, I also don't think that we should be forcing users to specify the scheme each time: many people would simply pick a random label to make the error go away, and we'll be in a worse position. – Uanfala (talk) 20:44, 7 January 2018 (UTC)

Are you sure? If I write:

{{transl/sandbox|ar|DIN|al-Ḫawārizmī}} → al-Ḫawārizmī → al-Ḫawārizmī

I have specified a transliteration standard DIN

If I write:

{{transl/sandbox|ar|al-Ḫawārizmī}} → al-Ḫawārizmī → al-Ḫawārizmī

I have not specified a transliteration standard. The template only knows that I have specified a language code but makes no statement about a standard.

and If I write:

{{transl/sandbox|arab|al-Ḫawārizmī}} → al-Ḫawārizmī → al-Ḫawārizmī

again, I have not specified a transliteration standard. The template only knows that I have specified a script code but makes no statement about a standard. The lang= attribute is omitted because Arab doesn't necessarily apply only to the Arabic language; the template should be tweaked to be 'Arabic-script transliteration'.

I think that the only way to get one of the named transliteration standards into the rendered tooltip is to specify a transliteration standard (ISO, DIN, etc) along with a matching language or script code. Am I wrong or am I not understanding your complaint?

—Trappist the monk (talk) 22:49, 7 January 2018 (UTC)

Ah, I think I had simply misunderstood the template's code (I've probably carried over that mistaken notion from the early days when my understanding of how templates work was even worse than it is now) – sorry, my bad! So yeah, my complaint is null and void. – Uanfala (talk) 23:07, 7 January 2018 (UTC)

I have applied better error handling with its own category (Category:Transl template errors). I have also added support for |italic= using the same set of accepted values as the {{lang}} and {{lang-??}} templates use. See Template:transl/testcases.

Without objection, within the next day or so, I intend to update Module:lang and will at the same time, update this template to use that module. The error category and help text will be created before this change.

—Trappist the monk (talk) 13:15, 11 January 2018 (UTC)

Now using the module.

—Trappist the monk (talk) 12:00, 13 January 2018 (UTC)

@Trappist the monk: I've undone your change as whatever it did caused errors in Vashti and other articles. --NeilN ^{talk to me} 17:51, 13 January 2018 (UTC)

I think that you have pulled the trigger without looking to see what it is that you are shooting. Vashti uses {{Hebrew name}}. That template has this:

[[Modern Hebrew|Modern]] ''{{Transl|he||{{{stan|{{{2}}}}}}}}''

The error that you saw at Vashti was:

[Vaští] error: {{transl}}: unrecognized transliteration standard: (help)

When three parameters are supplied to {{transl}}, {{{1}}} is the language code (he) {{{2}}} is the transliteration standard (here blank but should be one of ALA, ALA-LC, DIN, IAST, ISO), and {{{3}}} is the transliterated text (Vaští). This error indicates that the calling template is malformed as can be seen by inspecting the template call that is in {{Hebrew name}} (and reproduced above).

I suggest that the correct action that you should have taken was to fix {{Hebrew name}} or to have reported the problem here or at my talk page. Instead you have shot the messenger for merely reporting the existence of a malformed template call. I have fixed {{Hebrew name}}. Please restore {{transl}}.

—Trappist the monk (talk) 18:35, 13 January 2018 (UTC)

@Trappist the monk: I'm not sure where you're getting "shooting the messenger" from. I did report the problem here so others familiar with the template could look into it. I didn't know how long that would take so I undid the change so our readers wounldn't encounter the error in the mean time. --NeilN ^{talk to me} 18:47, 13 January 2018 (UTC)

Yes, you did report here; after you had already reverted. The error message was not a Script error: message text here. indicating that something in the template and supporting module was horribly wrong. Instead, the error message is restrained and even has a help-text link so that editors can learn about what has gone amiss. You 'shot the messenger' because, from all appearances, reversion was your first course of action. Nothing at all was wrong with {{transl}} or its supporting module; both acted correctly given the inputs they received.

The {{transl}} error messages, despite beliefs to the contrary, are useful. The template relies on a data set to create tool tips in the rendered output. The template does not know about several transliteration standards that exist in article space transclusions of the template because no one has bothered to include them in the data set. The error messages allow us to discover and support them.

—Trappist the monk (talk) 19:38, 13 January 2018 (UTC)

List of transliteration standards has been expanded to include these:

BATR – Bikdash Arabic Transliteration Rules

BGN/PCGN – BGN/PCGN romanization

EAE – Encyclopaedia_Aethiopica

Hepburn – Hepburn romanization

Nihon-shiki – Nihon-shiki romanization

SATTS – Standard Arabic Technical Transliteration System

UNGEGN – United Nations Group of Experts on Geographical Names

Wehr – Hans Wehr transliteration

—Trappist the monk (talk) 12:53, 16 January 2018 (UTC)

Module:lang

Module:lang gives different/unexpected results. Like tagging texts with ar-Latn/el-Latn/he-Latn instead of trans. In other words, if you specified a style for Arabic/Greek/Hebrew..etc text, they would be used for that Latinized text! This is very painful and requires us to double specify style for non-Latin text + all of their theoretically possible transliteration tags! --Mahmudmasri (talk) 17:16, 14 January 2018 (UTC)

@Mahmudmasri: I don't clearly understand what it is that you are complaining about. Can you show examples of what you think is wrong and what it is that you need to do to 'fix' it?

—Trappist the monk (talk) 18:25, 14 January 2018 (UTC)

If you tag a text using {{lang|ar-Latn|ʿarabī}} rather than {{transl|ar|????|ʿarabī}}, the Latin text is rendered with the font-style specified for Arabic text.

Example: Arabic text is specified to be enlarged and uses Simplified Arabic font.

The {{lang|ar-Latn|ʿarabī}} method will use Simplified Arabic and enlarge the font for that Latin text. --Mahmudmasri (talk) 19:06, 14 January 2018 (UTC)

As far as I know, there is no specification for font-size or font-style for any text in {{lang}} unless you include |size=:

{{lang|ar-Latn|ʿarabī|size=1.5em}}

ʿarabī

ʿarabī

otherwise all text rendered by these templates inherits font size from its parent – {{transl}} does not support |size=.

If you can show me where such a specification for font-style and font-size exists, I'd like to see it.

—Trappist the monk (talk) 19:29, 14 January 2018 (UTC)

On the custom CSS. If you specify span[lang|=ar], that would be also used to render anything tagged with ar-Latn. You are breaking Wikimedia norms that have been used for years! --Mahmudmasri (talk) 22:36, 14 January 2018 (UTC)

But that's your personal css (User:Mahmudmasri/vector.css), not a site-wide specification – where I understand 'specification', as you have used the term, to be something akin to a requirements document. I would venture to guess that most editors do not use that kind of css and certainly none of the general readership does. When faced with the choice, the template must rank non-logged-in readers ahead of editors. For transliterated Arabic, the correct html attribute is lang="ar-latn".

—Trappist the monk (talk) 23:35, 14 January 2018 (UTC)

I wrote an example, but the same goes on for Greek, Hebrew or any other text. I'm not the only one who specifies styles for certain texts, therefore I used the special:mypage. Please refrain from personalizing the issue. --Mahmudmasri (talk) 22:14, 16 January 2018 (UTC)

Broken style

That last edit (or that) broke the style on articles such as Romanization of Arabic.

Now those

{{transl|ar|Wehr|ilā l-mamlaka al-maḡribīya}}

appear as
error: {{transl}}: unrecognized transliteration standard: Wehr (help)
instead of
ilā l-mamlaka al-maḡribīya
The corrupt edit needs to be annulled immediately and tested away! --Mahmudmasri (talk) 17:07, 14 January 2018 (UTC)

The example above attempts to use the transliteration standard "Wehr", which was not present in the template and which was silently ignored. That undocumented standard is now being highlighted as an error. The documentation for {{transl}} is currently unclear (to me) about how to fix the problem (perhaps in Module:Lang/data?) and where one can find a list of valid transliteration standards. Perhaps Trappist the monk could edify us on those matters. – Jonesey95 (talk) 17:43, 14 January 2018 (UTC)

As I poke around articles related to transliteration, I find a number of methods that do not appear to be supported by this template, like Bikdash Arabic Transliteration Rules, GOST 16876-71, and many others listed at Romanzation. I have been unable to find an ISO-style list of officially adopted methods, however. Do we just add schemes by request, or is there some official list that I haven't yet found? – Jonesey95 (talk) 17:53, 14 January 2018 (UTC)

The list of transliteration standards in Module:lang/data comes from the original {{transl}} template code. That code has remained essentially unchanged since 2007; most likely because no one knew that unlisted transliteration standards are, well, not listed. I know of no 'official list'. I am allowing these errors to accumulate in the error category for a bit so that I can add them to the data table just before I turn into a pumpkin for a couple of weeks.

List of ISO romanizations? Is that what you're looking for?

—Trappist the monk (talk) 18:16, 14 January 2018 (UTC)

I don't think so. That's just ISO, which is apparently a subset of transliteration methods. This seems like a hairball of a task. Do we decide to support Greeklish, for example? If so, or if not, on what grounds? Consensus, I suppose, but it's nice when consensus is based on some sort of rationale.

Would you consider hiding this error message (or showing it only in preview) while we wait for the job queue to populate the category? – Jonesey95 (talk) 18:24, 14 January 2018 (UTC)

When Greeklish becomes an international or academic standard then, sure, we can add it. We are moving away from 'made-up' things toward international standards. Why? Because en.wiki is an international encyclopedia which ought not be in the business of making stuff up. That's why several previously accepted IETF-like language tags have been modified to be private-use language tags compliant with IETF.

At this writing, there are 28 articles listed in Category:Transl template errors. That's hardly enough to worry about.

—Trappist the monk (talk) 18:40, 14 January 2018 (UTC)

Hans Wehr's transliteration is a very widely used academic standard transliteration and is documented here: Hans Wehr transliteration. It is not an ISO transliteration but that doesn't counter the fact that it is standard and is important for Arabic. ISO is usually less used for Arabic and is more buggy. --Mahmudmasri (talk) 18:31, 14 January 2018 (UTC)

An urgent revert is needed! @NeilN: --Mahmudmasri (talk) 22:38, 14 January 2018 (UTC)

@Mahmudmasri: Posted to WP:AN to get more eyes on this. --NeilN ^{talk to me} 22:51, 14 January 2018 (UTC)

For those admins coming here from WP:AN, please note that there is a middle ground between reverting and keeping the template as-is. If the red error message is the only problem, the error message could be hidden, or shown only in preview, until the errors are fixed in the articles. Error messages are currently showing on 71 articles out of 14,993 transclusions. – Jonesey95 (talk) 23:13, 14 January 2018 (UTC)

Additional standards have been added to the module, and now there are many fewer articles in the error category. Many of them, like Halah, show errors because they are missing required parameters or because the editor's intended language/script combination is unclear. – Jonesey95 (talk) 06:40, 19 January 2018 (UTC)

Forced italics?

The recent module implementation appears to format the text in italics by default. But many uses of the template are cases where italic text is not expected, e.g. proper nouns. This has broken lots of articles. --Paul_012 (talk) 02:44, 19 January 2018 (UTC)

See discussion of this topic at Template talk:Lang, especially (but not exclusively) this section. This template was recently modified to use Template:Lang, which italicizes Latin-script text by default (until a more sophisticated method is implemented). The editor primarily responsible for the recent fixes and updates has suggested a change that would address the minority of instances where the templates wrap proper nouns, but has gotten no traction. – Jonesey95 (talk) 03:00, 19 January 2018 (UTC)

Is opt-out functionality available in this template? In any case, the template documentation has not been updated to reflect the change. --Paul_012 (talk) 04:30, 19 January 2018 (UTC)

To suppress the default italicization of Latin scripts, add |italic=no. – Jonesey95 (talk) 06:42, 19 January 2018 (UTC)

I'm on wiki break so can't get to any of this until I return. What the documentation needs is a table that is something akin to the italic parameter tables at Template:Lang-x/doc/parameters. In essence, |italic= omitted, present but not set, is the same as |italic=default and |italic=yes; |italic=no forces text in {{transl}} to be upright regardless of external markup; |italic=unset renders text according to external style.

—Trappist the monk (talk) 11:47, 19 January 2018 (UTC)

Additional transliteration standards

While fixing pages with template errors I've noticed a handful of unsupported transliteration standards:

AHL for Academy of the Hebrew Language
ArabTeX
Pinyin
REVISED or RR for Revised Romanization of Korean
YIVO

Should any or all of these be added? If not, should the articles that use them be changed to omit the scheme? DRMcCreedy (talk) 21:35, 27 January 2018 (UTC)

Certainly for those that you've listed above where en.wiki has an article detailing the romanization:

AHL – this one is somewhat detailed at Romanization of Hebrew
pinyin
RR

I'm not sure that the other two should. ArabTeX doesn't appear to be a romanization standard so much as it is a way of using Latin characters as input to typesetting software. While YIVO may have a transliteration standard, internally or externally, en.wiki has no article detailing that standard nor are the terms romanization or transliteration mentioned in the YIVO article.

I've added the three.

—Trappist the monk (talk) 11:02, 4 February 2018 (UTC)

In some instances there might be a specific template that could be more suitable than the generic {{transl}}, like {{lang-zh}} (for Pinyin). – Uanfala (talk) 15:55, 4 February 2018 (UTC)

Thanks for adding AHL, pinyin, and RR. DRMcCreedy (talk) 18:19, 4 February 2018 (UTC)

Special language codes for transliterations

Maybe this template could use the following language tags from Module:Language/data/iana variants: ja-Latn-hepburn for the Hepburn romanization of Japanese, yue-jyutping (not sure why that isn't yue-Latn-jyutping) for Jyutping (Cantonese), and zh-Latn-pinyin and zh-Latn-wadegile for pinyin and Wade–Giles (Mandarin). I think I've encountered Hepburn romanization quite often while cleaning up articles and haven't known how to tag it specifically. — Eru·tuon 03:31, 21 August 2018 (UTC)

Arabic still needs fixing

Hi. |ar| is still badly encoded, as you can see at Romanization of Arabic. The letters do not have a consistent format. Basic Latin letters are serif and presented at a reduced font size, while specialized letters are non-serif and overly large. On my browser at least, it looks liked the specified font does not include them, so the browser is filling in with another font. — kwami (talk) 16:48, 25 January 2019 (UTC)

@Kwamikagami: The Arabic transliteration looks okay in my browser (Linux, Firefox 64); it is being displayed in a single font (DejaVu Sans). But I've seen what you're referring to before. {{transl|ar|...}} doesn't affect font CSS-wise, as far as I can tell. It doesn't add inline CSS or contain anything that has any relevant CSS rules associated with it in the site CSS. It does apply the attribute lang="ar-Latn" so maybe your browser is adding fonts appropriate for Arabic script, which are less likely to have the special characters used in Arabic transliteration in them. It would help to add a CSS rule somewhere like :lang(ar-Latn) { font-family: <fonts with good support for characters used in Arabic transliteration>; }. — Eru·tuon 18:45, 25 January 2019 (UTC)

Thanks, Erutuon. Are you suggesting that for my personal CSS or as a general fix? — kwami (talk) 20:15, 25 January 2019 (UTC)

It would work in either case, but currently MediaWiki:Common.css doesn't include any language-specific stuff so adding something there might be a significant change in practice requiring a vote. I use [lang*="Latn"] { font-family: inherit; font-size: inherit; }. — Eru·tuon 21:19, 25 January 2019 (UTC)

Here's a screenshot when I logged out, zoomed in at 150%: — kwami (talk) 20:23, 25 January 2019 (UTC)

CSS

see Template talk:Lang#smart selection of css class—Preceding unsigned comment added by Dbachmann (talk • contribs) 14:55, 14 April 2007 (UTC)

Codes for transliteration schemes?

What are the codes for specifying the transliteration schemes? I see DIN, ALA and ISO in the examples. Also, is this template commonly used for Chinese and Japanese? --Apoc2400 (talk) 23:10, 20 December 2009 (UTC)

@Apoc2400: Dunno what the answer to your question was in 2009, but I had the same question today and after digging I believe this is the answer now. If not, hopefully someone will correct rather than delete. jnestorius^(talk) 17:47, 3 September 2020 (UTC)

Bug report: links within transl template

If I wikilink part of a word in any transl template, I can't stop wikilinking until the word ends or a non-ASCII character appears.

Trying to wikilink just the n gives: naïvité
Trying to wikilink just the ï gives: naïvité
Trying to wikilink just the i gives: naïvité
Trying to wikilink just the f gives: naïfs omit diaëreses

I'd appreciate a fix if anyone can readily manage it. Cross-posted to Wikipedia:Requested templates. HLHJ (talk) 17:18, 5 September 2021 (UTC)

Not the fault, if that word can be applied here, of {{transl}}. Here are your examples without {{transl}}

[[n]]aïvité → naïvité – links 'Na' to N
na[[ï]]vité → naïvité – links 'ïvit to Ï
naïv[[i]]té → naïvité – links 'it' to I
naï[[f]]s omit diaëreses → naïfs omit diaëreses – links 'fs' to F

See Help:Link § Wikilinks (internal links).

—Trappist the monk (talk) 19:57, 5 September 2021 (UTC)

Thank you, Trappist the monk; I really should have done better testing! HLHJ (talk) 05:15, 6 September 2021 (UTC)

Requested move 22 February 2022

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. Noting that there is not a consensus to delete the redirect created as a result of the move. That would require an additional discussion at WP:RfD. (closed by non-admin page mover) Elli (talk | contribs) 20:47, 14 March 2022 (UTC)

Template:Transl → Template:Transliteration – This template "transliterates" the input text. So, the new title is more proper and complete than simply transl. Also, the part transl is common for both the words translation and transliteration. As such, this template should be moved to Template:Transliteration to provide natural disambiguation against Template:Translation. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 19:37, 22 February 2022 (UTC)

Support per nomination. It is indeed counterintuitive for one main title header to use the form Template:Translation and for another to use the ambiguous Template:Transl. —Roman Spinner (talk • contribs) 00:43, 23 February 2022 (UTC)
Support per nom. {{u|Sdkb}} ^talk 19:27, 24 February 2022 (UTC)
Opppose. This is an inline template, and so it's desirable that it should be called using as short a name as possible. That's why we have {{lang}} and not {{language}}. The ambiguity, however, is a real issue; a compromise between those two competing factors might be something like {{translit}}. – Uanfala (talk) 23:58, 26 February 2022 (UTC)
{{translit}} could be a redirect that people would be free to use. – Jonesey95 (talk) 02:17, 27 February 2022 (UTC)
Well, by the same logic then why bother with this RM given that the redirect {{transliteration}} exists and people are free to use it? A template's title should be the same as what's used in the examples in the documentation, which should be the same as what we choose to encourage in its use in articles. – Uanfala (talk) 03:46, 27 February 2022 (UTC)
For the same reason we moved all of the {{tl}} templates to {{template link}} etc.: Template function should be clear from the template name (this is a quote from a guideline), even while convenient redirects exist. – Jonesey95 (talk) 06:25, 27 February 2022 (UTC)
The template's function is clear enough already from the shorter title. As for the tl templates, they're not completely comparable, as they're not used in articles, so there's less need to have good wikicode. Still, half of them use abbrevited titles, the other half have long descriptive ones, which – as far as I can see from a quick sample – are down to either bold moves from 2020, or moves from 2021 citing this bizarre single-sentence RM of one template that received no participation. Also, in their own documentation the renamed templates still refer to themselves using the short forms. This is all a big mess, and I'm not sure why anyone would want to recreate it here. More relevant standards for comparison are {{sup}} (where an RM with actual participation failed), and {{lang}} and its whole family (to which {{transl}} properly belongs), which nobody that I know of has argued should be moved. – Uanfala (talk) 16:07, 27 February 2022 (UTC)
How do editors know whether "transl" is short for "translation" or "transliteration"? That is the reason for this discussion. The other templates cited above, like {{lang}}, have no such ambiguity. – Jonesey95 (talk) 16:09, 28 February 2022 (UTC)
Well, that's an argument for using "translit". As for the other templates not being ambiguous: that is not the case. {{Lang}}, for example, is ambiguous with {{language}}, {{expand language}} and with the lang-xx family.
Most single-word template names are ambiguous anyway, and even for the ones with longer titles a user won't normally know what they're for unless she's read at least be beginning of the documentation (example: can anyone tell without looking what exactly is the function of {{Template link general}}?). Similarly, a name like "transliteration" (or even "transliteration markup") won't give you much of a clue about what the template does unless you've read its documentation or seen it used in the wild. Still, I agree with the principle that templates should have clear and descriptive titles, and I support such renaming for almost all cases – infoboxes, navboxes/sidebars, citation templates, message templates, less common in-line templates... but not for the widely used inline templates. – Uanfala (talk) 16:38, 28 February 2022 (UTC)

there's less need to have good wikicode I completely disagree with this. Our non-mainspace templates should be as clear as our mainspace templates, for easy use and clarity. If we go down the path of considering mainspace templates being superior, then we would lose many editors that work in non-mainspace. 🐶 EpicPupper ^{(he/him | talk)} 21:12, 1 March 2022 (UTC)
We're veering off-topic here, but I agree with you that templates should be well-designed regardless of what namespace they're used in. However, that was not my point here. The need to have good, clean wikicode is important in articles, because there the code is likely going to stay on for decades, being read, edited, moved around and re-used. That's why it's worthwhile to police wikicode in articles in a way that doesn't make sense for talk pages like this one. What the wikicode looks like in my post here doesn't matter: people won't read it (unless they want to quote part of it in a reply), and they aren't supposed to edit it either. – Uanfala (talk) 23:07, 1 March 2022 (UTC)
Support - 'transl' has always felt a bit too close to 'translate', and it wouldn't be obvious that it means 'transliterate' if you encountered this template in-article without looking at the documentation; you'd be forgiven for thinking it refers to translations. We could keep 'transl' as a working shortened version of the template, in the same way {{convert}} and {{cvt}} are the same, if this move will also include a similar change (i.e., {{transliterate}} becoming the template proper, if that makes sense).--Ineffablebookkeeper (talk) ({{ping}} me!) 10:58, 2 March 2022 (UTC)
Support per Ineffablebookkeeper, "translate" and "translit" are very different things. "Transl" as the name would only make sense if it were referring to both or either. I usually don't see much point in renaming templates, but this makes sense. I would be okay with "translit" as well, but we may as well be complete. ASUKITE 20:15, 2 March 2022 (UTC)
Support without leaving a redirect. I was under the impression until recently that {{Transl}} was for {{Translate}}, not {{Transliteration}}. The fact that the longer name is a redirect to the shorter name is just as counter-intuitive. I would not be opposed to also creating {{Translit}} as a redirect, but "Transl" is not intuitive for "Transliteration." — Jkudlick ⚓ (talk) 00:15, 3 March 2022 (UTC)
That does make sense, but the template is transcluded on over 44,000 pages (not sure if that number includes other redirects) so if we decide not to leave a redirect we will have to address those pages first to avoid breaking things. ASUKITE 16:13, 3 March 2022 (UTC)
That should be easy enough to do. There are already bots that automatically subst or otherwise correct templates, so the WP:BAG should be able to quickly approve the task if necessary. — Jkudlick ⚓ (talk) 17:00, 3 March 2022 (UTC)
Tbf, I agree with your proposal in principle. There's lot of ambiguity, especially because {{translation}} produces transl., which is exactly what the name of this completely different Template is. But I also agree with Asukite that it has 44,000 transclusions (via other redirects or not), so we'd have to change all of them. Yes there are bots but I'm not very sure if we need to do so much here. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 17:54, 3 March 2022 (UTC)
Deleting the redirect from the old title is an obvious no-no: it won't bring any benefits, but it will bring harms (old revisions of pages getting broken, people finding that what they knew no longer works, etc.). However, if there is consensus to both rename the template and more strongly encourage the use of the new template name, then the replacement can be added to WP:AWB/TR (so that it's carried out as part of AWB's general fixes); running a bot just for that may go against WP:COSMETICBOT. – Uanfala (talk) 18:03, 3 March 2022 (UTC)
I'm in complete agreement here. Moving without redirect would mean that all page revisions prior to the move with show up as red-link and not as how they were supposed to be. But we must also strongly encourage transliteration going forward. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 18:14, 3 March 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

documentation change

At this edit, Editor Ineffablebookkeeper added this to the documentation:

However, use of {{lang|xx-Latn|...}} can cause discrepancies in font display when used for transliteration; as such, {{transl|xx|...}} is preferred for transliterations.

@Editor Ineffablebookkeeper: do you have any examples that show that what you wrote is true?

—Trappist the monk (talk) 13:18, 22 March 2022 (UTC)

@Trappist the monk: ooh, I'll have to dig this up from the depths of my Talk page, but I remember having this conversation with another editor about a year or two ago. On certain browsers, use of the -Latn parameter ends up displaying, say, transliterated Japanese text in a font built to support Japanese characters first and English second, so it sort of stands out from the surrounding text as a different font, even though it's in the Latin alphabet. For instance:

Hana {{lang|ja-Latn|Hana}}

Hana {{transl|ja|Hana}}

Both display identically to me, in the correct font.

However, on my Talk page archives here, it seems that, on my crunchy, powered-by-diesel laptop, they would display differently:

Might be me being stupid here. The point of the FOREIGNITALIC stuff is to make sure it's not jarring when you're using casual foreign terms, but it seems like the lang templates in certain browsers deliberately sets off the text (which is the only reason I noticed it in the first place)—so the text was weirdly a different typeface and looked bizarre in the plot summary... but it doesn't seem to do it on all the browsers and OS configurations I've tried, so I guess it's a specific setting. So I dunno. I hate it aesthetically because it looks like someone mad-libbed the text, but at the same times that's the point of the templates. I guess disregard. Der Wohltemperierte Fuchs talk 18:11, 29 January 2021 (UTC)
Aha, don't worry! I think on my other (very dead at the minute) laptop, it does display differently. It's not a problem! It does look like a ransom note cut out of a newspaper at times, lmao. --Ineffablebookkeeper (talk) 21:10, 29 January 2021 (UTC)

Again, not sure what sets this off; I don't think it's user-defined CSS, as I'm not clever enough for that, and it's not different operating systems, as both this laptop and my hybrid petrol-and-coal-powered laptop operate on Windows 7 with Google Chrome. I have encountered at least one editor removing them in puzzlement in the past, thinking they were an error or a misused template. Though both templates do the same thing, I've been replacing ja-Latn lang tags with {{transl}} regardless for a while now.--Ineffablebookkeeper (talk) ({{ping}} me!) 11:14, 24 March 2022 (UTC)

That is a browser issue and has nothing to do with the template. Compare:

Hana ← Hana ← {{lang|ja-Latn|Hana}}
Hana ← Hana ← {{transl|ja|Hana}}

The important part of those is Hana which is the same for both {{lang}} and {{transl}}.

I have removed the above mentioned statement from the documentation.

—Trappist the monk (talk) 14:25, 24 March 2022 (UTC)