User talk:Kephir/gadgets/xte

Some older discussions: Wiktionary:Grease pit/2012/October#xte

Chinese

Could the following codes all be replaced with "cmn" without breaking anything?

zh-cn
zh-tw
zho
zhx-zho

Thank you, Mglovesfun (talk) 12:04, 1 November 2012 (UTC)

Well, I could do that. It may be a reasonably safe assumption that "Chinese", when the specific variation is unspecified, almost always means Mandarin. However, I have been bitten by "reasonably safe" assumptions a few times, so I would rather treat this as a "suspicious" case, to be marked with {{ttbc}} by default. Keφr (talk) 14:24, 1 November 2012 (UTC)

You're right; zh has already failed RFD, zh-cn and zh-tw are listed but I think will pass for no consensus, zho and zhx-zho are listed and will likely fail. I will probably close and re-list zh-cn and zh-tw because the discussion has gone dead. So carry on as normal until any relevant deletion takes place. Mglovesfun (talk) 13:53, 6 November 2012 (UTC)

These four have failed the deletion process and been removed from the javascript. Mglovesfun (talk) 10:54, 12 November 2012 (UTC)

I see. This is simply a lookup table mapping language codes to names, from which a reverse mapping table is generated. The script will normally fall back to querying the API to expand "{{langrev|name}}" when a name absent from the table is found. So, if Template:langrev/Chinese is deleted (like it looks it is going to), it will no longer recognise "Chinese" as a language, and therefore no longer process "Chinese" entries. Just so you know what you did. I guess "Chinese" should be treated like "Sorbian" now? Keφr (talk) 14:43, 12 November 2012 (UTC)

Watchlist

It seems to me that entries edited with this tool are automatically watchlisted. Could we remove this? It would put me off using it. Mglovesfun (talk) 12:34, 1 November 2012 (UTC)

Flush your caches and the default "watch" flag should now reflect your preferences. (Which was actually the originally intended behaviour; I just made a mistaken assumption while preparing a form for submission). You can always toggle the "watch this page" box before saving. Keφr (talk) 14:13, 1 November 2012 (UTC)

No, it only watchlists the page after you save it, so it has to be manually removed. It is only one click, but when you're trying to process dozens of pages in a row, that's dozens of clicks, and it get irritating. Mglovesfun (talk) 12:19, 4 November 2012 (UTC)

Strange. The tool only submits modified page source to show a diff, while making sure that the "watch" box will be appropriately checked (or not). Saving the page should work just like normal editing. I have no idea what can cause this. Keφr (talk) 15:07, 4 November 2012 (UTC)

Unwikified links always become ttbc

Something like

* Afrikaans: neptunium

becomes:

* {{ttbc|af}}: {{t|af|neptunium}}

I would prefer:

* Afrikaans: {{t|af|neptunium}}

I guess that's because all unwikified text becomes a single link unless there are any of several characters in there (,/( to name but three). But sure when there are no spaces it's pretty safe to just call it a valid translation? Mglovesfun (talk) 12:25, 4 November 2012 (UTC)

Done. Keφr (talk) 15:12, 4 November 2012 (UTC)

I actually think it was better before. If the original editor chose not to linkify it, then either (1) they don't know what they're doing, so a {{ttbc}} is a good idea, or (2) they do know what they're doing, and intentionally decided there shouldn't be a link, so we shouldn't just automatedly override that without at least a {{ttbc}}. —Ruakh_TALK 15:16, 4 November 2012 (UTC)

Can you find an example where either of those hold true? I don't think I've ever seen a case of an unlinked translation where {{t|foo|barrrrrr}} wasn't what the editor intended. Additionally, I think equating technical ineptitude with linguistic ineptitude is ridiculous ("they don't know what they're doing"). —Μετάknowledge^{discuss/deeds} 15:24, 4 November 2012 (UTC)

Re: "I think equating technical ineptitude with linguistic ineptitude is ridiculous": Then it's a good thing I didn't. ;-)   All I mean is, someone who doesn't understand even the basics of wiki-editing is very likely to miss important things, such as gender, (non)-capitalization, and the use of separate translations-tables for separate senses. —Ruakh_TALK 15:40, 4 November 2012 (UTC)

Re: very likely. Um, evidence? Because the evidence I'm seeing is showing the opposite. I the case of neptunium my best guess is the editor was trying to avoid writing neptunium because of the automatic black link. Mglovesfun (talk) 15:43, 4 November 2012 (UTC)

Your comment doesn't hold together. You start by saying that you see evidence that even "someone who doesn't understand even the basics of wiki-editing" is not "likely to miss […] "; but then the only actual example of you give is of a case that, in your estimation, falls under my "(2) they do know what they're doing".
Also, it's worth keeping in mind that this script still allows you to continue editing before you save; so all I'm saying is that I think it makes sense to err on the side of caution, adding {{ttbc}} until some human has looked at it.
—Ruakh_TALK 17:16, 4 November 2012 (UTC)

Then, I don't think your comment "holds together" either. Shouldn't we also then ttbc words that use square brackets? Being able to use square brackets doesn't indicate a mastery of wikisyntax you know. Mglovesfun (talk) 13:57, 6 November 2012 (UTC)

You may be right. If I have time tonight, I'll scan the database dump and see where we have unlinkified translations, for a more data-driven decision. —Ruakh_TALK 18:08, 6 November 2012 (UTC)

irregular context tags

I've noticed on some entries that had irregular context tags such as the following:

* Language: [[entry]] ''context''

Your script generated this:

* Language: {{t|code|entry ''context''}}

I think your script should at the very least recognize that italicized text does not belong in a link and maybe even recognize this as a context tag and format it as such.

--WikiTiki89 12:38, 4 November 2012 (UTC)

Ugh, I thought I was handling this already. Can you point me to a specific page where this happens, so I can test? Keφr (talk) 15:27, 4 November 2012 (UTC)

[[dictionary]] —Μετάknowledge^{discuss/deeds} 15:36, 4 November 2012 (UTC)

Hmm, the Xhosa entry has [[idikshinari]] ''noun 5'', but my tool did not put "''noun 5''" in a link, instead treating it as extraneous markup — that is, keeping it untouched, attached to the fixed entry. You probably have cached an old version of the script. Flush your cache and retry. Yes, I could treat it like a {{qualifier}}; however I have seen cases where it is rather some sort of inflection information that ideally should be put on the target page. So maybe calling attention to it is somewhat beneficial. But I am not sure. Thoughts? Keφr (talk) 15:46, 4 November 2012 (UTC)

I guess you're right. My cache was not flushed. But anyway, I think it would still be a good idea to make it a qualifier since if it is inflection information, that's where it belongs anyway if anywhere and since it is still marked for checking, someone will check it. --WikiTiki89 17:08, 4 November 2012 (UTC)

Simpler general-purpose version

How difficult would it be to create another simpler version for more general-purpose use? For example, so stuff like this doesn't have to be done by hand? --WikiTiki89 13:40, 5 November 2012 (UTC)

What do you mean by "more general-purpose use"? I mean the UI part specifically. I am quite uninspired. Keφr (talk) 16:30, 5 November 2012 (UTC)

Well maybe not completely general but something that would work for Descendants sections and maybe others that I can't think of at the moment. This should be simple since there won't be any fancy stuff just basically convert plainlinks to {{l|xx|word}}. --WikiTiki89 18:11, 5 November 2012 (UTC)

Piped links

In this edit, the script takes Old English [[onginnan|onġinnan]] and turns it into {{t|ang|onġinnan|sc=Latinx}}. I appreciate that ttbc is a good thing here, but the intention of the editor seems pretty clear, that is {{t|ang|onginnan|alt=onġinnan|sc=Latinx}}. I'm not a programmer so I have no idea how hard this is to implement, but if you can implement this change, please do. Mglovesfun (talk) 13:55, 6 November 2012 (UTC)

This is a known problem. To detect this case correctly, I would need an algorithm which removes vowel (or whatever) marks, which will probably be script- or even language-specific. It might be as simple as removing certain Unicode code points and/or substituting others, but I will have to gather the information about that from somewhere, it will probably be a quite big chunk of data, and I am not sure where to look for it (and whether I will not forget about some rare cases). As for the algorithm itself, this does not seem very hard. It is more of a question of feasibility. Keφr (talk) 19:04, 6 November 2012 (UTC)

impf and pf.

Can you recognize {{impf}} and {{pf.}} as pretty much the same as gender tags ({{m}}, {{f}}, etc.) and put them in the same place as gender would go? That would help out a lot with Slavic languages. --WikiTiki89 17:24, 6 November 2012 (UTC)

Done. I remember it used not to work, but now I see {{t}} has been changed to allow this. Though I cannot help myself but vaguely remember some opposition to treating {{pf.}} and {{impf}} like that… But personally, I think this makes sense. Keφr (talk) 19:13, 6 November 2012 (UTC)

Doesn't work at thrice

Could this be because of the alternative translation table template? --WikiTiki89 14:31, 14 November 2012 (UTC)

Precisely because of that. Fixed. Keφr (talk) 17:33, 14 November 2012 (UTC)

fullwidth problems

The Japanese translation at [[blockade]] uses fullwidth punctuation. Can your script be modified to recognize that? Or would that be too much work (in which case I can fix it manually)? --WikiTiki89 13:36, 20 November 2012 (UTC)

It could be done and it seems relatively easy, but does this happen very frequently? Risking introduction of a subtle bug may be not worth it. Keφr (talk) 10:24, 24 November 2012 (UTC)

Chinese to nested translations

Hi,

Great script. Could you please add the expansion of translations into Chinese from:

* Chinese: ... (on the same line)

or:

* Mandarin: ... (on the same line)

into:

* Chinese:
*: Mandarin: ... (on the 2nd line)

If the structure is no like that and there is no word Mandarin or Chinese (one or the other)?

Another request. There are still translations into Serbian (sr). Can this be replaced with Serbo-Croatian (sh) if it doesn't exist? --Anatoli ^{(обсудить}/^вклад) 10:33, 22 April 2013 (UTC)

Sorry for the delay. Done everything except putting "Mandarin" under "Chinese" group — I think a bot can handle this safely (I might have seen one doing this already, but I am unsure), and doing this in xte would probably require a significant rewrite, which I am not really willing to do. Keφr (talk) 09:07, 8 May 2013 (UTC)

Dziękuję bardzo! Appreciate this. --Anatoli ^{(обсудить}/^вклад) 23:04, 8 May 2013 (UTC)

Some hints on alternatives

Not sure if it's technically difficult but [[LINK|DISPLAY]] could be converted to {{t|LANGUAGE CODE|LINK|alt=DISPLAY}}. Similar to {{l|LANGUAGE CODE|LINK|DISPLAY}} = {{t|LANGUAGE CODE|LINK|alt=DISPLAY}}. That will fix Arabic/Hebrew vocalised writing, Russian accented forms, etc.

For example, Arabic {{Arab|[[عَذَاب]]|[[عذاب]]}} (‎ʿaḏāb‎) {{m}} could be converted as عَذَاب m (‎ʿaḏāb‎) and Russian [[карандаш|каранда́ш]] could be converted as каранда́ш m (karandáš).

Multiple [ [ ] ] [ [ ] ], including pipes ("|") could be converted to use {{t-SOP}} [[с]] [[день|днём]] [[рождение|рождения]] to {{tø|ru|[[с]] [[день|днём]] [[рождение|рождения]]}}. Result: с днём рожде́ния (s dnjom roždénija) .--Anatoli ^{(обсудить}/^вклад) 00:29, 17 May 2013 (UTC)

Done, more or less. I still cannot detect whether the link text is a simply a vocalised spelling or not; so now all single-piped-link entries are treated with |alt=. (Though WT:EDIT has some code for stripping vocal marks, I could use that.) Technically it is actually rather simple. It was done this way because of my assumption that idiomatic translations would be more prevalent, but running this script through Wiktionary convinced me that the opposite is the case. Keφr 07:23, 18 May 2013 (UTC)

Thank you. It may not be the unvocalised form only but a lemma form, so just using the default pipe to alt conversion seems safer. --Anatoli ^{(обсудить}/^вклад) 12:04, 18 May 2013 (UTC)

Rejecting non-Latin scripts in qualifiers

I oppose this change. I use qualifiers in foreign languages when a broader term needs some explanations both English and FL speakers. --Anatoli ^{(обсудить}/^вклад) 12:04, 18 May 2013 (UTC)

This change applies only to text found in parentheses for which no other meaning can be guessed (xte does not process items already using {{t}}; not yet, at least). I figured that sometimes parentheses are used to signify that a part of a phrase is optional, which would be a misuse of {{qualifier}}. Since, as I think, qualifiers should be in English most of the time (I cannot think of a situation in which they should not be, actually), rejecting non-Latin-script text as qualifiers allows to catch at least some cases of that. Keφr 13:10, 18 May 2013 (UTC)

So you not changing the existing {{qualifier}}? It's good then, I'll withdraw. An example would be половик m (polovík) (для вытира́ния о́буви) (doormat), подставка (ru) f (podstávka) (под столо́вый прибо́р) (place mat). Without a qualifier the terms are used more generically (have much broader meanings than the English terms). And the "optional" thing in a FL in brackets usually IS the qualifier like above. --Anatoli ^{(обсудить}/^вклад) 13:27, 18 May 2013 (UTC)

Hmm. The documentation for {{qualifier}} says it should be used "e.g. to qualify a synonym with a region or register", which to me seems rather dissimilar to this kind of use. I think such nuances in meaning should be probably explained on the target page and not clutter the translation list, since they are more relevant when translating into English, not from English. Keφr 13:49, 18 May 2013 (UTC)

impf/pf as a gender

There is some discussion about this at Wiktionary:Beer parlour/2013/June#Do we want "imperfective" and "perfective" to be treated as genders?. It affects your script so I wanted to let you know. —CodeCat 22:58, 24 June 2013 (UTC)

Translations to be checked

Does this script also convert the translations listed under a {{checktrans-top}} header? —CodeCat 23:37, 30 June 2013 (UTC)

Random stuff

When a translation is in a language that has a transliteration module, is in a non-Latin script, and does not have the string tr=, can the gadget propose a transliteration? That could be a helpful thing to clean up on the side. —Μετάknowledge^{discuss/deeds} 21:40, 1 September 2013 (UTC)

Is it not added automatically by {{t}} anyway? Keφr 21:56, 1 September 2013 (UTC)

Stupid me, of course it does. The problem was that we don't in fact have a translit module for WT:ETHI yet. New request: If there's an English translation, can the tool simply remove it? —Μετάknowledge^{discuss/deeds} 22:04, 1 September 2013 (UTC)

As in... translation into English? These things exist? Oh, I see... I think it could, it would be kind of a dirty hack though... on the other hand, so is the rest of the script. But are you sure removal is always the best idea? Keφr 22:19, 1 September 2013 (UTC)

I feel sure that it can never be valid, so yes, I would advocate for removal. The script should also remove translations into appendix-only languages per current consensus, for example at abacus#Translations (Lingua Franca Nova translation). —Μετάknowledge^{discuss/deeds} 22:24, 1 September 2013 (UTC)

I cannot detect whether a language is appendix-only without adding a massive overhead for each run. Or loading the whole Module:languages database at the start, which is somewhat large: about 600 KiB of JSON. It can be cached, but it would still be the largest resource to be downloaded and kept in memory. Doing it would shorten the source code a lot, though.

The philosophy behind this tool, however, is (or at least was) not to do things which a proper bot (as opposed to the "human flesh bot" who operates xte) can handle. I think you should ask at Module talk:translations to add detection of these cases. Keφr 22:33, 1 September 2013 (UTC)

The list of appendix-only languages that have codes is pretty short, I can't imagine how the overhead would be a problem. Or just handle those appendix-only languages that have an ISO code, which is a very small set indeed. I know this is meant for human use, but that doesn't exclude this kind of thing, and TBH these problems may be more common than we would like to think. —Μετάknowledge^{discuss/deeds} 22:41, 1 September 2013 (UTC)

I think a far easier method would be to make {{t}} show a script error if it's given any of those languages? —CodeCat 22:43, 1 September 2013 (UTC)

...which is pretty much what I thought. Keφr 22:55, 1 September 2013 (UTC)

It doesn't make any difference to me, but I am incapable of effecting either solution due to my incompetence, so if you would prefer to have it throw a script error and then remove everything that gets caught, that's fine, but then I would appreciate it if you could edit the module thus. —Μετάknowledge^{discuss/deeds} 18:35, 2 September 2013 (UTC)

Chinese again

Hi,

Could you change your tool, so it doesn't change the word "Chinese" to "trreq|Chinese", please? It only adds to more editing. It's clear enough that it has to be Mandarin, Cantonese, etc. --Anatoli ^{(обсудить}/^вклад) 06:11, 2 September 2013 (UTC)

This tool does not use {{trreq}} at all. Keφr 10:30, 2 September 2013 (UTC)

Oops, sorry. I meant ttbc. --Anatoli ^{(обсудить}/^вклад) 11:18, 2 September 2013 (UTC)

Last time I checked (w:WP:BYPASS if it does not work for you), it turned "Chinese" into "{{ttbc|cmn}}", so it already defaults to Mandarin. All it takes is to change "ttbc|" into "subst:". I am rather anxious to simply put "Mandarin" there by default. Keφr 11:58, 2 September 2013 (UTC)

That was my original request too, if you remember, could you please do it? As it happens, currently the tool helps with other languages but less with Mandarin, as nesting needs to be added manually and the ttbc formatting needs to be removed.

There are also annoying zh-ts and zh-tsp templates in Chinese translations, which are not processed by the tool, I wonder if you can convert those into {{t}}? --Anatoli ^{(обсудить}/^вклад) 22:18, 2 September 2013 (UTC)

I do not know what they should be replaced with. A quick scan of the dump reveals about 570 quite consistent uses of the template in translation tables. I think they could be handled by a real bot. Just watch out for "Pinyin", "Taiwan" or "PRC" in transcriptions. Good luck. Keφr 23:19, 2 September 2013 (UTC)

The logic is easy. "t" stands for traditional, "s" for simplified, "p" for piyin, {{zh-ts}} has only the first two and the pinyin is in brackets. The other request is more important. 570 is actually manageable, will convert manually eventually. --Anatoli ^{(обсудить}/^вклад) 05:34, 3 September 2013 (UTC)

I've been running a bot to replace language names with codes on these two templates, using {{langrev}} as the reference. {{langrev/Chinese}} gives "cmn", so if your script doesn't do the replacement mine probably would have. —CodeCat 13:37, 2 September 2013 (UTC)

Umm... okay... like I wrote, it already defaults to Mandarin, wrapped in {{ttbc}}. If you can check the translation, do that yourself. I shall err on the side of caution and not assume that the translation needs no attention.

By the way: why does {{langrev}} not use Module:languages? Keφr 14:52, 2 September 2013 (UTC)

Well, with Serbo-Croatian you just convert without adding ttbc around the language name, could you please do the same for Chinese? Nobody ever added a Chinese dialect/topolect translation under "Chinese", only Cantonese, Min Nan, etc. Those translation are all Mandarin. --Anatoli ^{(обсудить}/^вклад) 22:28, 2 September 2013 (UTC)

Actually no, the names of national varieties of Serbo-Croatian are replaced with {{ttbc|sh}}. The translations themselves are probably correct, but they need to be sorted, and redundant ones removed, and we seem to have no other template for marking specific translations for attention. So {{ttbc}} it is. A cursory scan of the dump suggests that you may be right about "Chinese" translations being Mandarin, but I know none of these languages and so I shall reserve judgement. Keφr 23:19, 2 September 2013 (UTC)

Hmm, until recently you only converted the Serbo-Croatian translations to use {{t}}, leaving the words "Bosnian", "Croatian", "Serbian" as they are. If you changed it, I don't think it would make editing easier. It's much easier to change Serbian to Serbo-Croatian manually than {{ttbc|sh}} to Serbo-Croatian when checking. With Chinese, I'd prefer (as a minimum) conversion to {{t}} without any other change (i.e. Chinese -> {{ttbc|cmn}} + the comment). As a maximum, nested translation (Chinese/Mandarin) would be better. I hope you want to listen to some feedback. I do a lot of Chinese translations and I find your tool quite useful otherwise but with Mandarin it just makes a bit harder at the moment. Mandarin translations are being regularly checked and corrected anyway but it would be made much easier if you could make the change. --Anatoli ^{(обсудить}/^вклад) 23:33, 2 September 2013 (UTC)

It could, but there are some things to take into account that might break current uses of the template. {{langrev}} currently doesn't allow for ambiguity; if a name exists, it can be for one code only. But Module:languages allows many languages to share names, as long as their primary names are all unique. So what would happen when two languages share the same name as one of their alternatives? —CodeCat 17:48, 2 September 2013 (UTC)

I would check for a second match and throw an error. But good point. On the other hand, why is that so, how are the alternative names currently used, and must it remain that way? Keφr 18:30, 2 September 2013 (UTC)

leg

The script made an incorrect edit on this page that caused a script error in the Swahili translation. It interpreted the second word as a separate translation with two noun classes and plural gender, but noun classes and genders can't be mixed so this causes an error. The second translation should really have been removed, and the two noun classes applied to the first, because the standard practice is not to list inflected forms in translations. —CodeCat 12:18, 15 September 2013 (UTC)

Something similar happened on lip as well. —CodeCat 12:20, 15 September 2013 (UTC)

Actually that was me: I often check and correct the proposed changes before saving. My tool does not recognise noun class annotations at all. Thanks for noticing. Keφr 12:35, 15 September 2013 (UTC)

last night

It messed up the Russian translation rather bad... —CodeCat 19:21, 15 September 2013 (UTC)

It was messed up from the beginning (missing bracket pair). Nice catch. Keφr 19:27, 15 September 2013 (UTC)

I only found it because of the script error. Some people might not like them but they are good for something. —CodeCat 19:28, 15 September 2013 (UTC)

Script errors are not that bad. It is just their appearance which is… less than perfect. Keφr 19:30, 15 September 2013 (UTC)

Apache

• Apache — <name not recognised by xte: update Template:langrev and Module:languages appropriately or report to User talk:Kephir/gadgets/xte>

We have been using Apache in Translation tables for nesting the various Apachean languages, including Western Apache, Mescalero Apache, Chiricahua Apache, Jicarilla Apache, Lipan Apache, and Plains Apache. —Stephen ^(Talk) 23:16, 18 September 2013 (UTC)

Okay, made it handle that. Though in the end it just means that the error message changes… Keφr 06:05, 19 September 2013 (UTC)

Ancient (see for)

under Preposition/Translations in "for" ({{ttbc|Ancient}} name not recognised by xte) — Although "Ancient Greek" is still found as a language in translation tables, it is generally entered as a sub-heading under "Greek" thus:

• Greek: λόγος

  Ancient: λόγος
  — Saltmarsh^{απάντηση} 05:53, 24 September 2013 (UTC)

• Ouch. I actually already check for this, but I got the check slightly wrong. Fixed. Keφr 06:01, 24 September 2013 (UTC)

Not working

The tool's no longer working for me. --Anatoli ^{(обсудить}/^вклад) 23:53, 14 November 2013 (UTC)

"Please wait a moment until language data is downloaded."

"Please wait a moment until language data is downloaded." is the message I get and nothing happens when I try to edit cousin or even bowleg with much less translations. --Anatoli ^{(обсудить}/^вклад) 06:39, 15 November 2013 (UTC)

Everything works fine for me. Your browser? Have you tried w:WP:BYPASSing? I made a small mistake in the script, now corrected. Keφr 15:56, 15 November 2013 (UTC)

Still does not work. --WikiTiki89 22:27, 15 November 2013 (UTC)

Thanks, I have cleared the cache but it didn't help. My browser is Mozilla Firefox 25 on Windows XP and Windows 7 (two computers). --Anatoli ^{(обсудить}/^вклад) 02:59, 16 November 2013 (UTC)

Fixed. Though why are you not using the global menu anyway? Keφr 06:25, 16 November 2013 (UTC)

Thanks. Not sure what the global menu is. --Anatoli ^{(обсудить}/^вклад) 09:51, 16 November 2013 (UTC)

Right next to the "watch" tab. Keφr 10:00, 16 November 2013 (UTC)

I did use it. --Anatoli ^{(обсудить}/^вклад) 10:09, 16 November 2013 (UTC)

Gurmukhi, Shahmukhi

On [[Punjabi]], it looks like your script got tripped up by someone's decision to specify Gurmukhi-script Punjabi and Shahmukhi-script Punjabi on different lines, the way Latin- and Cyrillic-script Serbo-Croatian are on different lines. I have updated scriptrev and Module:scripts; I don't suppose anything else needs to be done(?). - -sche (discuss) 03:13, 7 December 2013 (UTC)

Marquesan

Apparently, the two Marquesan varieties are sometimes grouped under one header: [1]. - -sche (discuss) 20:00, 7 December 2013 (UTC)

Teochew

...is a variety of Min Nan, but perhaps distinct enough to be allowed its own line in trans tables. (If not, it should be treated as Min Nan, and qualified.) It's found in tables like this one. - -sche (discuss) 20:10, 7 December 2013 (UTC)

Sahidic and Bohairic

... are the two most prominent dialects of Coptic (which also has other dialects). They are seen e.g. in the table in [[yours]]. I've added them and a number of other dialects' names to Module:languages: [2]. - -sche (discuss) 20:11, 7 December 2013 (UTC)

Awesome script!

Hi, can the script be modified to remove any manual transliterations different from the automated ones and any redundant transliterations? —Aɴɢʀ (talk) 08:10, 27 January 2014 (UTC)

Miwok

Please let the gadget recognize Miwok as a cover name for all of the Miwok languages (csi, csm, lmw, mkq, nsq, pmw, skd) since it makes sense to group them together in translation tables. —Aɴɢʀ (talk) 12:37, 15 February 2014 (UTC)

Can I turn it off?

I tried xte in order to be able to look up language codes, but found that I prefer to use the list of languages for that. xte adds quite a bit of overhead to my transactions all over the site, including in namespaces that should never have translation tables. Especially annoying is when I click edit, click in the edit box, then xte finishes setting itself up and the focus is taken away from the edit box, forcing me to click again before I can start typing. I'm sure it would be worth it if I were actually using xte for the purpose it was designed for, but I do basically nothing with translation tables most of the time.

How do I deactivate xte or remove it? Simply unchecking it in the per-browser preferences seems to have no effect. Also, this should really be addressed in your documentation. Thanks, Chuck Entz (talk) 19:22, 25 April 2014 (UTC)

In order:

0. Yes, you can.
1. I actually took measures to ensure that the data is downloaded only once per browser session (might add localStorage/sessionStorage to the list).
2. xte does not get involved with input focus at all. Must be something else.
3. This is a fault in WT:PREFS, it seems.
4. Which of the above exactly?

— Keφr 19:51, 25 April 2014 (UTC)

re: 1- A typical case is when I'm browsing through the diffs on one of the forums (which takes a long time as it is), and I get the "xte failed to grab the language details" message. I would think that xte shouldn't be automatically trying to grab anything except in main space or in appendix space. Anywhere else, you should have to click something. Also, I sometimes will empty an obsolete category by opening a number of entries in separate tabs in order to do a null edit on each one and force it to propagate a change in a template it's transcluding. Even tiny delays add up when multiplied over dozens of entries.

re: xte and focus- I'm not saying xte is taking the focus, just that it's delaying the step that does so long enough for it to happen long after my click. I'm not even saying that xte is the only culprit- just that I'd rather not have any extra contribution to the problem.

In general, I think it would be a great improvement to have the ability to turn off the automatic stuff other than the loading of the menu itself (i.e. put it in "sleep mode") so that one isn't faced with the choice of either having it do all kinds of unnecessary things in the background everywhere one goes/everything one does, or removing the gadget entirely.

In my case, though, I don't do anything where xte would be useful, so any extra overhead is undesirable. I'm not really knocking the gadget itself- I just want to remove it from my browser. How do I do that? Chuck Entz (talk) 20:43, 25 April 2014 (UTC)

You undo whatever you did to install it. (The usual yadda yadda about w:WP:BYPASSing browser cache may apply or not.) — Keφr 04:07, 26 April 2014 (UTC)

"Whatever I did" was clicking a checkbox in the per-browser preferences. Un-clicking that didn't work, even after the stuff at w:WP:BYPASS. I guess I'll have to check at the Grease Pit. Chuck Entz (talk) 15:37, 26 April 2014 (UTC)

Move it out of user space?

This gadget is now fairly widely used, so I think it should be put in MediaWiki: space like some other gadgets. That would indicate that it's no longer a personal script, but is "owned" and maintained by Wiktionary collectively. —CodeCat 20:04, 25 April 2014 (UTC)

I think we have gadgets far more in need to be moved into the MediaWiki space than this one. Also, it kind of is a personal script: I have never actually decided what its feature scope is, the only criterion for adding a feature is that "I found it useful". — Keφr 06:33, 27 April 2014 (UTC)

Russian {{l/ru}}

Could such examples be converted to normal {{t}} instead? I don't see any reason to use {{l/ru}} in translations. --Anatoli ^{(обсудить}/^вклад) 03:29, 16 June 2014 (UTC)

They will be now. — Keφr 03:35, 16 June 2014 (UTC)

OK, thanks, I misread before. --Anatoli ^{(обсудить}/^вклад) 03:52, 16 June 2014 (UTC)

Kalispel-Pend d'Oreille

The language called Flathead (code fla) is more appropriately called Kalispel-Pend d'Oreille or Montana Salish. —Stephen ^(Talk) 11:33, 22 September 2014 (UTC)

…thanks for the info? — Keφr 15:33, 22 September 2014 (UTC)

{{#invoke:languages/templates|getByCode|fla|getCanonicalName}} resolves to "Montana Salish", so we're good. —Aɴɢʀ (talk) 18:28, 22 September 2014 (UTC)

Why is this showing up in Category:Serbo-Croatian terms needing attention

?--Ivan Štambuk (talk) 17:54, 30 September 2014 (UTC)

The JavaScript file that includes the code for adding the {{attention|sh}} template when translations labeled as Bosnian, Serbian or Croatian are encountered has a string consisting of: 'Serbo-Croatian {{attention|sh|was "' + name + '"; verify correctness, check for duplicates, mark script, sort and merge if appropriate}}:'. I've seen user's Common.js files showing up in maintenance categories before, so I'm not surprised. Maybe there should be a comment with <nowiki> at the start of the file and a comment with </nowiki> at the end so the system won't try to parse it as wikitext.Chuck Entz (talk) 01:37, 1 October 2014 (UTC)

I went ahead and added the nowikis- needless to say, you're welcome to revert if it causes problems. The js page is no longer in Category:Serbo-Croatian terms needing attention, and, as a bonus, it's dropped out of Category:Pages with module errors/hidden, where it had been for quite a while. Chuck Entz (talk) 14:18, 1 October 2014 (UTC)

An irritating error keeps popping up

saying "xte: error while processing language data. See console for details."

I get the following picture from the console:

►Uncaught TypeError: Cannot read property '0' of undefined index.php?title=User:Kephir/gadgets/xte.js&action=raw&ctype=text/javascript:52

--Dixtosa (talk) 20:01, 23 July 2015 (UTC)