Open main menu

Avoiding having to keep some things synchronizedEdit

Would it be possible to use this notation to store the common Hani+Jpan+Kore info under only one of those codes, so they no longer have to be kept synchronized by hand? - -sche (discuss) 09:28, 28 December 2013 (UTC)

We can't do that because we have used square brackets inside the strings. --Z 09:32, 28 December 2013 (UTC)
That can be changed, though. Maybe we should. —CodeCat 16:41, 28 December 2013 (UTC)
Maybe we should just consider merging "polytonic" with "Grek". Are there really that many fonts that can't display polytonic symbols? --WikiTiki89 17:23, 28 December 2013 (UTC)


Should "Romaji" and "Rōmaji" be added as alternative names of Latn, or Jpan? (I'm guessing "Latn"...) - -sche (discuss) 19:14, 10 June 2014 (UTC)

I guess so. Keφr 21:18, 10 June 2014 (UTC)

Font support for Latin Extended-DEdit

Quivira 4.0 provides complete support for the Latin Extended-D block, AFAIK, and is a free font. Is there a way of having use that font display the characters in this range (U+A720–U+A7FF)? — I.S.M.E.T.A. 03:49, 29 June 2014 (UTC)

MediaWiki talk:Common.css would be the place to ask it. Keφr 08:22, 29 June 2014 (UTC)
Thanks, Keφr. I've done just that. — I.S.M.E.T.A. 17:12, 30 June 2014 (UTC)

Georgian scriptEdit

copied here from Wiktionary:Grease pit/2013/December

ISO 15924 gave two codes to the three scripts used by Georgian: Nuskhuri and Asomtavruli are Geok, Mkhedruli (the usual Georgian script) is Geor. Separately, the ISO gave the scripts 2–3 blocks of codes: the characters from Ⴀ-Ⴭ are Asomtavruli, and the characters right after them, from ა-ჿ, are Mkhedruli ([1]); ⴀ-ⴭ is Nuskhuri. Currently, Module:scripts/data defines Geor (Georgian, i.e. Mkhedruli) as including the characters of Asomtavruli, but I recently added Geok (defined as including these same characters). FYI. (Note: because several of the aforementioned characters just look like boxes on my computer, I may have made some typos.) - -sche (discuss) 23:45, 21 December 2013 (UTC)

So why does Geor include Asomtavruli?
Also, Asomtavruli and Khutsuri are not other names of Nuskhuri. Nuskhuri does not have other names. Khutsuri is a combination of Asomtavruli and Nuskuri, and thus not an independent script. Therefore having a script code for it is awkward.
Anyways, why do we need the code Geok at all? We do not and will not use any of the older scripts.--Dixtosa (talk) 15:38, 18 April 2015 (UTC)
Re "why does Geor include Asomtavruli?": I don't know; it was like that when I got here. I wrote what I wrote above in the hope that someone would clarify whether or not it was problematic for Asomtavruli to be listed under two different codes.
Re "why do we need the code Geok?": even if we don't have entries for terms written in the older scripts, we'll have entries for the individual letters that make up those scripts, and it's possible that words written in the older scripts will be mentioned somewhere, e.g. in citations. It's helpful to have the characters mapped to a script code which is, in turn, mapped by MediaWiki talk:Common.css to fonts that display the characters correctly. But we could use Geor to cover all Georgian scripts, if the fonts we use for it (DejaVu Sans, Arial Unicode MS, Sylfaen) handle Asomtavruli and Nuskuri reasonably well.
Re the names: I've switched Geor to have Khutsuri as the canonical name and Asomtavruli and Nuskuri as otherNames. The otherNames field (here and in Module:languages) is not just for synonyms of the canonical name, but also for the names of parts that are subsumed into the code in question. Hence if we subsumed Khutsuri / Asomtavruli / Nuskuri into Geor, I would think they should be listed in the otherNames field.
- -sche (discuss) 03:37, 19 April 2015 (UTC)

Font support for Latin Extended-EEdit

Since the recent version 4.1 update, Quivira now supports completely both the Latin Extended-D and Latin Extended-E Unicode character blocks. Quivira is already the default font for Latinx. Currently, Latinx does not include any characters in the Latin Extended-E block. Accordingly, could someone who can change the character statement for Latinx in Module:scripts/data from "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿ" to "0-z¡-ɏḀ-ỿⱠ-Ɀ꜠-ꟿꬰ-ꭥ", please? — I.S.M.E.T.A. 15:24, 2 September 2014 (UTC)

RFM discussion: July 2013–January 2015Edit

The following discussion has been moved from Wiktionary:Requests for moves, mergers and splits (permalink).

This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.

The first option brings it in line with other script codes like Template:fa-Arab and Template:nv-Latn. The language code in the name doesn't have any meaning in itself, it's just to give a meaningful distinction.

The second makes it more compliant with the official language subtag registry, which recognises "polyton" as a subtag to indicate polytonic Greek (not as a script code in itself!). See [2]. This option is probably the more "correct" of the two. —CodeCat 13:06, 23 July 2013 (UTC)

Grek-polyton is preferable because not all Greek written in polytonic is Ancient Greek. Modern Greek is officially defined as starting in 1453 and it was written in polytonic for over 500 years after that. —Angr 09:12, 27 July 2013 (UTC)
Like I said, the language code doesn't mean it's used only for Ancient Greek, it just means "the Ancient Greek script variety" or "the variety of the script associated with Ancient Greek". In the same way, "fa-Arab" is used by many other languages beside Persian. —CodeCat 11:14, 27 July 2013 (UTC)

Not renamed. The script code in Module:scripts/data was not changed either. Keφr 14:04, 3 January 2015 (UTC)

Please update Thai, Laoo, LanaEdit

For Thai:

characters = "ก-๛",

For Laoo:

characters = "ກ-ໟ",

For Lana:

characters = "ᨠ-᪭",

(I have placed correct characters.) --Octahedron80 (talk) 03:15, 13 August 2015 (UTC)

All done. (no change for Lana) Wyang (talk) 05:02, 25 May 2016 (UTC)

Formatting error with ThaiEdit

See Wiktionary:List of scripts Instead of Thai, the Thai flag is displayed and the columns are off by one, shifted to the right. —Justin (koavf)TCM 14:14, 3 January 2016 (UTC)


Please update "Mymr" to support all extensions, since Mon and Shan (and more) use characters beyond current range. Also add an alias.

m["Mymr"] = {
	canonicalName = "Burmese",
	otherNames = {"Myanmar"},
	characters = "က-႟ꩠ-ꩿꧠ-ꧾ",
	systems = {"abugida"},

--Octahedron80 (talk) 04:45, 25 May 2016 (UTC)

Done. Wyang (talk) 05:01, 25 May 2016 (UTC)


What is currently use of systems = {"abugida"} ? And is there another possible value? --Octahedron80 (talk) 01:41, 2 November 2016 (UTC)

Updating to clear out Category:Unspecified script languagesEdit

Several of these are known (e.g. Bandi/Gbandi or bza is Latn). Can someone either unprotect this to allow it to be updated or make a bot that can mass-import these values? —Justin (koavf)TCM 01:22, 26 May 2017 (UTC)

Some of them are known. Did you have a specific source you wanted to import the data from? DTLHS (talk) 06:13, 26 May 2017 (UTC)
I unprotected this now. (to be edited by autoconfirmed users) Note that once Wikidata access is implemented here, I'd expect all this script information to be moved there somehow if people don't mind, but I guess it can't hurt to have this module updated before moving all the information there. --Daniel Carrero (talk) 06:18, 26 May 2017 (UTC)
Actually, I don't think this is the module that has to be updated to clear out the unspecified script languages category; it's the language data modules that give the scripts for a particular language. — Eru·tuon 07:19, 26 May 2017 (UTC)
If that's the case, I suppose we can give template editor status to Koavf? --Daniel Carrero (talk) 07:34, 26 May 2017 (UTC)
Good point. Koavf had also posted about Category:Unspecified script characters, which is controlled by this module (AFAICT), but the languages are a different matter. - -sche (discuss) 08:18, 26 May 2017 (UTC)

No characters for Zyyy ("undetermined")?Edit

Not adding characters = m["Latn"].characters for Zyyy is problematic as it causes the templates to ask for transliteration for reconstructed words which are written in Latin, e.g. in *ganzabara-. --Z 11:37, 6 June 2017 (UTC)

Hmm, an alternative is to add "Latn" as xme's script, as the script our entries are written in (regardless of whether or not it was used by the Medians themselves); we also do that with languages which are so far only attested in scholarly works that use Latin script (even when they are spoken in e.g. India and China and would possibly switch to using Deva or Hani if they were eventually written natively); OTOH, we don't list Latn as a script of Gothic or Proto-Runic. Another idea is to add a special code for "reconstructed-language Latin", maybe "und-Latn", and add it as the script of xme etc. However, what you propose is probably the best idea. (I suppose there will be no new side effects to Latin-script characters being listed as belonging not just to Latin but to Zyyy, since they are already also listed as belonging to a number of other scripts.) - -sche (discuss) 13:37, 6 June 2017 (UTC)

I have added this. --Z 11:15, 10 June 2017 (UTC)

Oh, the change doesn't fix the problem, but I shouldadd Latn to xme in the language data modules. --Z 11:24, 10 June 2017 (UTC)

Hmm, adding characters = m["Latn"].characters to Zyyy did not fix the problem? I wonder if that is because xme explicitly listed Zyyy as its script? Only two languages do that, out of the hundreds with no known native script (and of those two, Sentinelese has no content), so it appears to be non-normal (the norm seems to be to list no script), and maybe modules/templates don't handle it well. Purely unattested (proto-) languages often have Latinx as their script, so setting Median to Grek, Latn seems appropriate. - -sche (discuss) 16:38, 10 June 2017 (UTC)
I see why now, after checking the relevant module that adds "transliteration needed", I think it would also fix by adding Latn before Zyyy, not the other way around as I have done in my edit in the data module. --Z 20:52, 10 June 2017 (UTC)
Return to "scripts/data" page.