Wiktionary

Wiktionary:Grease pit/2016/December

< Wiktionary:Grease pit

๛ edit

The Thai symbol ๛ has a broken head-word line and label. The formatting seems fine. I think it has to do with the symbol itself. Maybe it needs to be listed in the Module:th-translit? —Stephen (Talk) 07:28, 1 December 2016 (UTC)[reply]

@Wyang —Μετάknowledgediscuss/deeds 18:01, 5 December 2016 (UTC)[reply]
I'm not sure why this occurs - it seems to be a problem with a generic template or module. Wyang (talk) 01:21, 8 December 2016 (UTC)[reply]
When I compare ๛ with ๆ (both being Thai punctuation), ๆ works correctly; but ๛ is broken in {{th-punctuation mark|head=๛}} as well as {{lb|th|archaic}}.
If I place the following lines as the only contents of ๛, then all four templates are broken. But if I place them as the sole contents of ๆ, then all four templates work correctly.
===Punctuation mark===
Template:th-punctuation mark
  1. (archaic) punctuation
===Punctuation mark===
Template:th-punctuation mark
  1. (archaic) punctuation
And if I change the language parameters to km, then there is no problem anywhere. So the problem seems to be the symbol ๛ itself, but only if it is marked as Thai.
Just for grins, I looked at Module:th. I don't know anything about Lua, but the symbol ๆ appears in Module:th as "ๆ"; while the symbol ๛ appears as [ก-๛] and [^ก-๛{}%-]. Could that be the cause? I also looked in Module:th-pron, but I did not think it was the cause of the problem. —Stephen (Talk) 17:45, 13 April 2017 (UTC)[reply]

Automatically generate topical labels from the categories edit

Not long ago, someone was wondering why there was not automatically a label X for each Category:en:X. Of course, that's because the label data and category data are entirely separate, but I am thinking they could be combined. That way, a lot of our topical label data, currently in Module:labels/data/topical, becomes redundant. Whenever a new topical category is created, you get a label that puts entries in that category, "for free". While this is kind of a proposal, I am not expecting significant opposition to this and I am asking more about the feasibility of the idea.

There are, of course, some topical categories where the label and the category name don't match, such as analysis ~ Mathematical analysis or canoeing ~ Water sports. It can be argued that in these cases, they should be made to match. In the case of "analysis", it could be aliased to "mathematical analysis", which is clearer as a label anyway. And for "canoeing", if it warrants its own context, we could consider why it doesn't have its own Category:Canoeing either.

Another point to look at is set-type categories. Membership of a set, such as "days of the week", is not grounds for a context label {{lb|xx|days of the week}} or similar, because that's simply not a topical context. Wednesday is not used primarily when talking about days of the week. So we'll have to exclude set-type categories from the automatic process, which I suppose could be done simply by looking if the parent categories include "List of sets". —CodeCat 20:43, 1 December 2016 (UTC)[reply]

I like that this would more directly tie senses to categories. The display issue is my only concern, but that can be automated (maybe) or a component of the data. I do wish there was a better way to store the label data, the current structure is awful. - TheDaveRoss 13:53, 2 December 2016 (UTC)[reply]
Well, this idea would mean the label data is not stored at all, but derived on the fly from the category data. At least for topical categories, anyway. What is your concern about the label data specifically? —CodeCat 02:11, 5 December 2016 (UTC)[reply]
It is a bummer to have to store relational data in a flat file with no way to enforce structure. It would be idea if we could connect modules to an actual SQL database of some kind, so that the data could be stored in a more robust and easily maintained format. An example, there are a number of labels which are "deprecated," but there is no easy way to see which labels those are, or who deprecated them, or what they should be replaced with, etc. The more labels which are available the worse that situation will get. It isn't a design flaw, it is a platform limitation. - TheDaveRoss 14:24, 5 December 2016 (UTC)[reply]

Thai transliteration for SoP terms edit

It doesn't always transliterate Thai terms when there are more words separated by [ [ ] ]. What needs to happen so that คนลาว is transliterated automatically? คน (kon) and ลาว (laao) work fine separately. @Wyang, Octahedron80, CodeCat What are your opinions? Is it Module:links or Module:th? Hopefully you won't fight but offer a solution :) --Anatoli T. (обсудить/вклад) 02:08, 5 December 2016 (UTC)[reply]

Hi Anatoli, I haven't looked into this but AFAIK {{th-x}} offers a similar output - {{th-x|คน ลาว}}: คนลาว(kon laao). Wyang (talk) 01:14, 8 December 2016 (UTC)[reply]
@Wyang Thanks, Frank. I know {{th-x}} and other language specific templates work fine for this but unfortunately the other templates and templates don't. Having SoP terms with [ [ ] ] [ [ ] ] is quite common.--Anatoli T. (обсудить/вклад) 01:53, 8 December 2016 (UTC)[reply]

"Topic labels" are now always linked, leading to bad red links edit

See e.g. Reingold-Tilford algorithm, where "computing theory" is a red link. I have recently seen this on other topic labels too. Has someone introduced a bug here? Equinox ◑ 14:10, 5 December 2016 (UTC)[reply]

Not a bug so much as a feature that needs fine tuning. You can override the link by specifying display = in the data modules. —CodeCat 15:41, 5 December 2016 (UTC)[reply]
No, it's a bug, and I assume you did it. Where was the consensus for this change demonstrated? —Μετάknowledgediscuss/deeds 17:59, 5 December 2016 (UTC)[reply]
I also oppose this. --WikiTiki89 18:55, 5 December 2016 (UTC)[reply]
@Wikitiki89: Is this the edit in question? I would revert it, but I don't want to make more of a mess by accident. —Μετάknowledgediscuss/deeds 19:01, 5 December 2016 (UTC)[reply]
No, seemingly that edit only makes the label link to the English section if it is already a link. --WikiTiki89 19:05, 5 December 2016 (UTC)[reply]
  Done: diff. --WikiTiki89 19:23, 5 December 2016 (UTC)[reply]

@Wikitiki89 It seems like something went wrong, currently no topic labels are linked, even if they should be (see, e.g., dialog box). --Einstein2 (talk) 22:33, 10 December 2016 (UTC)[reply]

Apparently Metaknowledge considers the links a bug, so it was removed. —CodeCat 23:01, 10 December 2016 (UTC)[reply]
CodeCat, I find your behaviour very frustrating. I think you know that you are misrepresenting my viewpoint, and are doing so just because I disagree with the change that you made without consulting anyone else, which you have been repeatedly told by many editors in the past to stop doing. That status quo before your changes was perfectly fine. —Μετάknowledgediscuss/deeds 23:18, 10 December 2016 (UTC)[reply]
The status quo linked labels inconsistently. With my change, entries were linked by default unless overridden not to, so that labels that needed to be linked now were. What's wrong with that? Now, all links are removed, which is a step back from the former behaviour. —CodeCat 23:23, 10 December 2016 (UTC)[reply]
The inconsistency was useful; it linked them where appropriate, and didn't where it wasn't — and we could modify this as we saw fit. I'm not happy with the lack of links either. The problem is that we needed to be having this conversation before your edits, and not after them. —Μετάknowledgediscuss/deeds 00:33, 11 December 2016 (UTC)[reply]
All that has changed is that, whereas before, not linking was the default, now linking is the default. In the former case, it could be overridden by providing a linked form, in the new case it can be overridden by providing an unlinked form. So they are functionally equivalent, but because we want links on most terms, linking is a better default than not linking. —CodeCat 02:11, 11 December 2016 (UTC)[reply]
That would only be "all that has changed" if you had updated the existing categories to keep their link or non-link status. The sudden appearance of red links as a result of you not doing this is the problem and indeed is the title of this discussion thread. Equinox ◑ 11:43, 11 December 2016 (UTC)[reply]
Frankly, I would prefer if no topic labels were ever linked at all. --Dan Polansky (talk) 13:43, 11 December 2016 (UTC)[reply]
I think that ideally all labels should link to our appendix glossary. Linking to a main entry is a lazy temporary solution. Linking to main entries blindly when they might not even have the relevant content is a really bad solution, even worse than the redlinks. --WikiTiki89 15:10, 12 December 2016 (UTC)[reply]
Are you saying that even topic labels, such as Australian rules football or graphical user interface, should have their own lines at Appendix:Glossary instead of linking them to the entries Australian rules football and graphical user interface? – Einstein2 (talk) 14:20, 13 December 2016 (UTC)[reply]
Hmm... that is a good a point. Linking to their Wikipedia articles would also not be bad idea. In practice your particular examples are not much of a problem only because it is very unlikely that other new senses will be added to the entries Australian rules football and graphical user interface, so those are not the ones I would prioritize fixing. Certainly for topics whose entries are polysemous or even lacking the relevant sense, it is much more important that we either link to the glossary or the Wikipedia article instead. --WikiTiki89 16:03, 13 December 2016 (UTC)[reply]

Can we improve Wiktionary:Translation requests? edit

Whenever someone uses this feature we generate "From [insert source language] to [insert target language]" as the subject and "[insert text here]" as the text. Nobody ever (very slight exaggeration) changes "[insert source language]" or "[insert target language]" to actual languages, and neither do they change "[insert text here]" to actual text. Is there an easy way that we can show people what they are actually supposed to do? SemperBlotto (talk) 15:01, 5 December 2016 (UTC)[reply]

Oddly enough it seems to have been okay before mid-November or so. Did something change around that time? — Kleio (t · c) 15:27, 5 December 2016 (UTC)[reply]
  • IMO, a good idea would be to have two dropdown lists, for source and target language. They start off both defaulted to "English"; if the user does not change them such that the two languages differ, the edit is blocked with an explanatory message, telling the user to choose. (No idea if we can do this.) Equinox ◑ 19:01, 5 December 2016 (UTC)[reply]
I think a better idea would be to display a form when you click "Make a new request" which has a field for "Source language", "Target language", and "Text", which will automatically post a new section when submitted, but cannot be submitted unless all three fields are filled. Someone who's good at JavaScript should be able to do that. --WikiTiki89 15:25, 6 December 2016 (UTC)[reply]

I am completely unable to create a new translation request. What seems to be wrong? I even believe I filled the source and target languages correctly in the predefined spaces in the section title. --Daniel Carrero (talk) 22:24, 6 December 2016 (UTC)[reply]

What happens when you do it? Any error message? Equinox ◑ 17:56, 8 December 2016 (UTC)[reply]
@Equinox: I was unable to save my new section (an English->Japanese request). An error message appeared saying that my edit was recognized as "harmful". Then I disabled the abuse filter. --Daniel Carrero (talk) 16:39, 9 December 2016 (UTC)[reply]

In-page anchors at Category:English lemmas edit

I would like to link directly to a section of that page (so that it scrolls down to that section automatically when somebody follows my link), but there's no table of contents with section links. Is it possible? Equinox ◑ 17:55, 8 December 2016 (UTC)[reply]

https://en.wiktionary.org/w/index.php?title=Category:English_lemmas&pagefrom=word lists pages in the category starting from 'word'. Is that what you've looking for? —suzukaze (t・c) 02:26, 9 December 2016 (UTC)[reply]
No, that particular page has quite a bit of content before it gets to the regular category listings, so I'm sure he's talking about specific parts of the page itself. All I can suggest is looking at the page source/inspecting the DOM and finding the closest id= (the body content is nested a number of levels in, so it may take a while if you go the inspecting route), which should work when linked to as something like [[:Category:English_lemmas#<the id>]]. Chuck Entz (talk) 04:24, 9 December 2016 (UTC)[reply]
Haha, I'm a user (here), I'm not going to "inspect a DOM". Is there any sane workaround? I can link to sections on most wiki pages, e.g. French or Noun. I am guessing the issue relates to the use of en-categoryTOC in some way...? Equinox ◑ 00:36, 14 December 2016 (UTC)[reply]
Well, I went ahead and looked at the source: CAT:English lemmas#mw-subcategories should get you to the Subcategories header, and CAT:English lemmas#mw-pages should get you to the 'Pages in category "English lemmas"' header. In most browsers it's just a matter of either right-clicking on the page body and selecting "view source" or hitting control-u if the right-clicking doesn't work, then control-f and search for "id=". Anything following "id=" in the html is an anchor you can link to. Chuck Entz (talk) 04:09, 14 December 2016 (UTC)[reply]
I don't really see this as a satisfactory solution because it seems less safe to rely on "internal" HTML ids staying the same than on the editable markup staying the same (all other factors being equal). But I'll use it, because it's only my stupid user page, and I appreciate you taking the time to check it out. (Another downside: apparently I have to use the absolute URI like this [1] and not a normal wiki link that can be red or blue.) Equinox ◑ 05:05, 14 December 2016 (UTC)[reply]

Displaying Special:WhatLinksHere/ numbers edit

Is there a function in existence that displays the number of pages that link to a given page, in a similar way to the {{PAGESINCAT:}} function for numbers of members in categories? — I.S.M.E.T.A. 21:31, 8 December 2016 (UTC)[reply]

This question has received answers at Wiktionary:Information desk/2016/December#Displaying Special:WhatLinksHere/ numbers. — I.S.M.E.T.A. 17:45, 9 December 2016 (UTC)[reply]

Language data edit edit

Please add the following to zu: 

	entry_name = {
		from = {"[āàáâǎ]", "[ēèéêě]", "[īìíîǐ]", "[ōòóôǒ]", "[ūùúûǔ]", "ḿ", "[ǹńň]", MACRON, ACUTE, GRAVE, CIRC, CARON},
		to   = {"a"      , "e"      , "i"      , "o"      , "u"      , "m", "n"    }},

—CodeCat 15:22, 11 December 2016 (UTC)[reply]

@CodeCat: Done. Also, what is the situation with hyphens like those in Zulu verbs? —JohnC5 16:45, 11 December 2016 (UTC)[reply]
Zulu verbs and adjectives are lemmatised with the bare stem, as is the norm in dictionaries and other reference works. The hyphen indicates that it's not a complete word. —CodeCat 16:47, 11 December 2016 (UTC)[reply]
But should we strip them out? —JohnC5 16:57, 11 December 2016 (UTC)[reply]
No, because there are genuine suffixes such as -isa as well. —CodeCat 17:15, 11 December 2016 (UTC)[reply]
Roger that. —JohnC5 18:12, 11 December 2016 (UTC)[reply]

Behaviour of template:lb edit

Surely {{lb}} should behave in the same manner with all of the following parameters:

  • Using "archaic"" - places the term in "Category: … terms with archaic senses"
  • Using "obsolete"" - places the term in "Category: … terms with obsolete senses"
  • Whereas "dated"" - places the term in "Category: … dated terms"
why not the Category: … terms with dated senses — Saltmarsh. 12:16, 13 December 2016 (UTC)[reply]
I'm asking for someone to modify {{lb}} - or justify this (IMHO) odd behaviour — Saltmarsh. 07:20, 14 December 2016 (UTC)[reply]

Template:wikibooks edit

Template:wikibooks is broken. If you supply it with a language parameter |lang= it will not spit out the correctly displayed language in the description of what Wikibooks is being linked to, unlike the equivalent Wikipedia template.

Wikibooks has more about this subject:
Wikibooks
Spanish Wikibooks has more about this subject:
Wikibooks es
 
English Wikipedia has an article on:
Wikipedia
 
Spanish Wikipedia has an article on:
Wikipedia es
{{wikibooks}} {{wikibooks|lang=es}} {{wikipedia}} {{wikipedia|lang=es}}

-- 65.94.168.229 09:37, 15 December 2016 (UTC)[reply]


Is there a template that takes an Wikimedia language code (or ISO-639 language code) and displays the language name? If so, I can fix this template simply. -- 65.94.168.229 06:47, 20 December 2016 (UTC)[reply]
There is a module, invocation as follows: {{#invoke:languages/templates|getByCode|en|getCanonicalName}} returns "English". - TheDaveRoss 14:39, 20 December 2016 (UTC)[reply]

So, the immediate problem is fixed, thanks to Dave Ross. It's still not internationalized/localized completely, as there's a cookbook parameter that only works in English, and I don't know the detailed structure of how WikiBooks operates in multiple languages -- 65.94.168.229 05:31, 21 December 2016 (UTC)[reply]

Problem with Archiver edit

The Archiver tool is malfunctioning – I just got the following error message (tried it twice): "Error: The parameters "pageid" and "oldid" can not be used together. [code invalidparammix]". — SMUconlaw (talk) 19:04, 16 December 2016 (UTC)[reply]

Me, too. Some more detail: I just tried using aWa to archive wt:RFD#bacter- and got that error message. This happened both with the default (archiving to [[talk:bacter-]] and to [[talk:bacteri-]]) and also (after a reload) after I dropped [[talk:bacteri-]] from the set of targets. I'm running Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0. Does anyone know what's going on, or a fix, please?​—msh210℠ (talk) 11:43, 19 December 2016 (UTC)[reply]
Can we file a ticket at the Phabricator? Do they work on gadgets? — SMUconlaw (talk) 14:44, 20 December 2016 (UTC)[reply]
For future reference, no. Basically, anything we have control over is not the developers' responsibility. The right thing to do is exactly what was done (i.e. "file" a "ticket" at the WT:GP). --WikiTiki89 16:41, 20 December 2016 (UTC)[reply]
  Fixed diff. --WikiTiki89 16:35, 20 December 2016 (UTC)[reply]
Thanks! — SMUconlaw (talk) 18:26, 20 December 2016 (UTC)[reply]

Category:etyl cleanup/en edit

There are many thousands of terms in this category. What are we supposed to do with them? SemperBlotto (talk) 15:15, 17 December 2016 (UTC)[reply]

Something like this. —Aɴɢʀ (talk) 16:49, 17 December 2016 (UTC)[reply]
Relatedly, is there any particular reason for which languages have their own etyl cleanup subcategories? Can I add new ones somehow? --Tropylium (talk) 17:34, 12 January 2017 (UTC)[reply]

Template:de-decl-adj-notcomp edit

This template produces incorrectly spelled forms. All the forms preceded by a definite or indefinite article should be capialized.

In addition, these same forms should not only be on erster and similar words. They need to be added to both erste and Erste and similar words. --Espoo (talk) 09:46, 18 December 2016 (UTC)[reply]

In German the capitalized forms are technically nouns. This template is however meant for the adjective forms i.e. der erste Tag not der Erste. I not sure if we should put an additional declension table for the derived nouns forms, as the only different feature would be capitalization. Matthias Buchmeier (talk) 11:16, 18 December 2016 (UTC)[reply]

Template:ISO 639 edit

Template:ISO 639 appears to be broken

{{ISO 639|zh|zho}} ISO 639-1 code zh, ISO 639-3 code zho (SIL)
{{ISO 639||chy}} ISO 639-3 code chy (SIL)
{{ISO 639|fi}} ISO 639-1 code fi

The auto-generated SIL link gives a 404-not-found for any language code provided -- 65.94.168.229 05:50, 21 December 2016 (UTC)[reply]

Looks like SIL broke it themselves, even internal links on their site to the ISO 639 area are 404. - TheDaveRoss 12:44, 21 December 2016 (UTC)[reply]
I got the point. The URL www.sil.org is changed to www-01.sil.org . Looks like they are going to renovate their website. I will follow this until new version comes. --Octahedron80 (talk) 05:08, 22 December 2016 (UTC)[reply]

Module:pa-translit edit

This was formerly a translit module that knew just one of the scripts used by this language. User:Octahedron80 moved that module to Module:Guru-translit and replaced it with:

local out_text
if (sc == 'Guru') then
out_text = require('Module:Guru-translit').tr(text, lang, sc, debug_mode)
elseif (sc == 'Deva') then
out_text = require('Module:sa-translit').tr(text, lang, sc, debug_mode)
elseif (sc == 'Arab') then
-- out_text = require('Module:Arab-translit').tr(text, lang, sc, debug_mode)
out_text = nil
else
error('Invalid script for Punjabi language.')
end
return out_text

The problem is that this very simple-minded code doesn't use the script-detection logic in our modules, and it throws a module error in any entries that don't have a |sc= parameter, falsely stating that they're in the wrong script. Given that the script detection in the modules has made |sc= parameters basically obsolete in most languages, this is guaranteed to cause confusion and frustration for anyone unlucky enough to be adding content in Punjabi.

Can someone fix this? Thanks! Chuck Entz (talk) 04:23, 22 December 2016 (UTC)[reply]

The script is already auto-detection from prior module that uses this like headword, so sc input is not needed. It is really useable and the same script tr modules can share among languages. (That's we call 'module'.) Some times ago, I also did this to Module:khb-translit. None of them show error. I'd like to see which page show error. --Octahedron80 (talk) 04:31, 22 December 2016 (UTC)[reply]
Sorry, I forgot to add 'pa-Arab' as well. Now no error occur. Until someone make Module:pa-Arab-translit, this case is set to nil for now. --Octahedron80 (talk) 04:49, 22 December 2016 (UTC)[reply]

Template:senseid and invisible module errors edit

This template uses Module:languages/templates to generate a language name that's part of the text fed to anchorencode:. This is great most of the time, but any module errors are converted into corrupted, but invisible html. The page goes in CAT:E, but there's nothing at the page itself to show where the error is. Unless you notice that there's something wrong with the |lang= parameter, looking at the wikitext doesn't help much, either. Is there some way to make it possible to see the error without having to look through the html? Chuck Entz (talk) 07:24, 24 December 2016 (UTC)[reply]

Template:&lit edit

Can this template be made to (optionally) suppress adding to Category:English idioms? I don't think it's right but if there are oppositions, please make it optional with a parameter. --Anatoli T. (обсудить/вклад) 00:45, 28 December 2016 (UTC)[reply]

Did you have a specific entry in mind? DTLHS (talk) 00:46, 28 December 2016 (UTC)[reply]
I meant that we don't need to add to idioms category. If it's not idiomatic, it's not kept, right? For entries like freedom of speech or be silent (currently in RFD) it definitely doesn't make sense. --Anatoli T. (обсудить/вклад) 00:52, 28 December 2016 (UTC)[reply]
Good catch. That seems eminently sensible. DCDuring TALK 20:05, 28 December 2016 (UTC)[reply]

dump edit

Is there a way to get a dump of Telugu lemmas? I'm sure I've seen something in regard to this before. I need a list which I can place in User:Rajasekhar1961/Appendix:List of Telugu words. It's for the purpose of populating Index:Telugu. —Stephen (Talk) 07:41, 28 December 2016 (UTC)[reply]

@Stephen G. Brown User:DTLHS/Telugu lemmas DTLHS (talk) 16:20, 28 December 2016 (UTC)[reply]
Beautiful! Thanks! —Stephen (Talk) 02:57, 29 December 2016 (UTC)[reply]

derivsee in Module:compound/templates edit

Multiple issues with the output of the derivsee function in the module compound/templates, which is used by {{suffixsee}} and {{prefixsee}}. It doesn't apply any language styles to the word in the title (for instance, ▼ Arabic words suffixed with جي, not ▼ Arabic words suffixed with جي) and italicizes the list of words with the suffix that you get when you click the down arrow. Ideally, both the suffix and the list should display with language-specific fonts, in the same way that the list of words in Cat:Arabic words suffixed with جي does. — Eru·tuon 09:30, 28 December 2016 (UTC)[reply]

I'm not sure if we can fix this- we could apply a global style to the header, but it wouldn't be language specific. DTLHS (talk) 01:51, 29 December 2016 (UTC)[reply]

Smartphone app? edit

Anyone ever used our app? Apparently it has a lousy interface. --Derrib9 (talk) 23:44, 28 December 2016 (UTC)[reply]

Spaces needed in Lao translit for usexes with brackets edit

Using Module:lo-translit I need to make it work for usexes, please. E.g. ປະເທດລາວ ― pa thētlāo ― Laos (country) has no space after the square brackets, it should insert a space, like this: "pa thēt lāo". Calling @Octahedron80, Wyang --Anatoli T. (обсудить/вклад) 01:47, 29 December 2016 (UTC)[reply]

Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2016/December&oldid=71472916"