Wiktionary:Grease pit/2008/May

Looking at the table of contents at you, "Determiner" appears to be a standard L3 header. Yet it has no edit link and it is editable with the preceding L4 translations section. The markup looks to be fine as well - I'm confused as to what's happening. Thryduulf 17:30, 1 May 2008 (UTC)

Well, I'm seeing it on the TOC, and I'm not seeing it when I edit the preceding L4, however, I too am without an edit link for the particular header. -Atelaes λάλει ἐμοί 17:50, 1 May 2008 (UTC)

The "editsection" code isn't being generated. (It is in the edit of the preceding L4, but I kept having trouble finding it because there is so much stuff ;-) Very odd. Robert Ullmann 18:02, 1 May 2008 (UTC)

Further, if you manually tweak the section-edit URIs to the right numbers (10 and 11 for the "Determiner" L3 section and its "Translations" subsection), you get a "No such section" error. —Ruakh_TALK 23:03, 1 May 2008 (UTC)

Very odd. I did find some problems with {checktrans-top} matched with a {trans-bottom}, but fixing that did not correct the problem. --EncycloPetey 00:30, 2 May 2008 (UTC)

I'd be mighty surprised if that affected anything as {{checktrans-bottom}} is just a redirect to {{trans-bottom}}, which itself is one of our simplest templates as it just ends the table and closes two divs. Thryduulf 00:45, 2 May 2008 (UTC)

Fiddling with this in userspace, I find that the problem is solved if I comment out or remove the second translation table ("object pronoun: the person being addressed"). However, I can see nothing there but standard templates and standard formatting. -- Visviva 03:20, 2 May 2008 (UTC)

Eureka! With Visviva's info I tracked down the problem. The Finnish translation line had two unclosed {{i}} templates. --EncycloPetey 03:31, 2 May 2008 (UTC)

Well done! And I imagine the reason the problem continued only into the ===Determiner=== ====Translations==== section is that that section has a bunch of unpaired }}s. I guess the software no longer generates edit-links for headers inside templates; which is probably a good thing, because it used to generate them wrongly. (To us it's obvious that {{i|===Foo===}} contains one header, but the parser can't tell that, at least not until it expands {{i}} and finds that its {{{1}}} ends up in the result exactly once.) —Ruakh_TALK 11:33, 2 May 2008 (UTC)

I remember on wp a couple of years back there was cleanup of unbalanced parentheses, square and curly brackets, etc (w:Wikipedia:WikiProject Wiki Syntax). Would it be of benefit to do something similar here? Or perhaps add some code to AF that notifies us when it finds an error? Thryduulf 12:08, 2 May 2008 (UTC)

A code and cleanup category sound like good ideas to me. --EncycloPetey 18:07, 2 May 2008 (UTC)

Before looking at what AF might do, the first thing would be to do some analysis of the dump, and see what can be found; that can generate a cleanup list. Something like User:Robert Ullmann/Mismatched wikisyntax perhaps? (It has you with the problem noted; but who would have ever found yttrandefrihet? ;-) Robert Ullmann 12:00, 3 May 2008 (UTC)

I've started working on that list, removing entries after I've fixed them (or ascertained they've already been fixed). I've also added sections to the page to make it a little more workable. Thryduulf 16:31, 3 May 2008 (UTC)

Um, the sections are going to get overwritten in a few minutes, as the code finishes re-checking everything against the "live" DB and re-writes the report. If we want sections to edit/strike, I'll have to put it in the code. I figure on re-running it as things get fixed. (as it only reports 10% of the issues now; and I've been improving the filters.) Robert Ullmann 16:42, 3 May 2008 (UTC)

I have improved User:Robert Ullmann/Mismatched wikisyntax to add convenient sections to work on, and improved the filters. The number of problems has been reduced from 2500+ to 1407. Please help if you'd like. Thryduulf has done a number of them, tx. Robert Ullmann 13:28, 9 May 2008 (UTC)

The way interwikis are added seems somewhat dysfunctional to me.

1. It is irritating to have to type something like ] ] ] when the pages all have exactly the same name, which is the same name as the English page to begin with. Couldn't some code be added to make a simpler option?
2. Why do we have to add these manually at all? On Wikipedia, there are bots which flesh out manually added interwikis, because obviously a bot can't find the correct corresponding encyclopedia entry. Given that Wiktionary interwikis go to the same word, why not just have omniscient interwiki bots that do it automatically? This would of course solve the previous problem also. -Oreo Priest 18:58, 2 May 2008 (UTC)

There are bots who does exactly this. See e.g. User:VolkovBot and User:Interwicket. On other wiktionaries are additional bots running. \Mike 19:15, 2 May 2008 (UTC)

It's got a good point though, it should be doable completely automagically in much the same way as unified login. Conrad.Irwin 19:17, 2 May 2008 (UTC)

Yeah, that's exactly what I meant, but didn't specify very clearly. Just like the unified login, we shouldn't have to chase down the page in every language, either by a bot or automagically, it should just happen. -Oreo Priest 19:30, 2 May 2008 (UTC)

Never fear, the bots will get round to it - but in this world of instant gratification why not make the WMF servers do it! Conrad.Irwin 19:34, 2 May 2008 (UTC)

So will these bots do what I meant? My impression was that VolkovBot at least only does the same matching of incomplete interwikis as on Wikipedia. -Oreo Priest 19:55, 2 May 2008 (UTC)

Not sure about VolkovBot, but Interwicket does exactly what you're describing (adding interwiki links to a;; pages of the same name on other wikts). I believe it crawls the pagetitles dump on a semi-regular basis; the last run finished on April 24, and I don't think there's been a fresh dump since then. Poke User:Robert Ullmann for more info. -- Visviva 05:53, 3 May 2008 (UTC)

Awesome. Thanks! -Oreo Priest 08:12, 3 May 2008 (UTC)

It is VERY helpful but rarely given here for some reason. Look at Russian Wiktionary - it is mandatory there, plus they use very nice formatting, color highlighted green&italic font and it given on the same string as definition - so it is space efficient. Plus they use "◆" for visual separation from definition and it is done using template... TestPilot 05:35, 3 May 2008 (UTC)

Rarely done here? We have bajillions of them. Can't say I care for the Russian layout myself; our standard layout at WT:ELE#Example sentences seems much crisper. The idea of making them mandatory doesn't sit well with me either -- there are plenty of obsolete and technical terms for which a made-up example would only generate confusion. -- Visviva 05:47, 3 May 2008 (UTC)

Really? Look here is Word of the day for March. Majority definitions lack it! And thous that actually have it - represent them different ways of formating. Examples: dearth, superlative and so forth and so on. Plus there is no color highlighting plus it take more space. And sure, usage is not 100% mandatory, but in 99 cases out of 100 it helpful. But look around, check random articles or articles from your watchlist, most of them do not provide examples for majority of meanings. Plus in case of template actual styling choice could be easily improved/changed anytime later. TestPilot 06:12, 3 May 2008 (UTC)

In a community of volunteers, no-one can force anyone to do anything. I try to add example sentences to all the definitions that I write, but there are a lot of times when, for one reason or another, these sentences haven't been written. The only thing I can really think of to propose is {{sofixit}}. Though I did have an idea for using javascript to make the addition of examples easier, maybe I'll have to give it another go... In terms of formatting all the sentences should be written as described in WT:ELE - it is (should we want to) customizable using CSS - and as the format is so standardized we could get a bot to change things drastically if we wanted. The Russian Wiktionary to me (probably because I can't understand the words) looks messy and confusing, as space isn't that much of an issue I think the extra line break adds a lot of clarity. Conrad.Irwin 09:03, 3 May 2008 (UTC)

Personally I never bother with WOTD, because the words there are invariably too common to be interesting and too rare to be important. It would certainly be nice if the WOTDs all had example sentences. -- Visviva 14:56, 5 May 2008 (UTC)

Is there a reason why the "lang=" parameter of some templates requires the language name, yet for others the same parameter requires the iso code of the language? Should we standardise on one or the other?

See maiks for the completely non-obvious juxtaposition of the two forms on a single entry. Thryduulf 14:26, 5 May 2008 (UTC)

The difference is in the function for which the template calls the parameter. In {{context}}, the lang= parameter is used to generate a topical category name, which requires the ISO code. In the case of {{plural of}}, the lang= parameter is used to generate a grammatical category, which reuqires the full English name of the language. Now, some templates like {{infl}} have been cleverly engineered to accept the ISO and from this generate the language name. However, this requires extra coding that has not been put into the older templates. --EncycloPetey 17:58, 5 May 2008 (UTC)

Many users (even experienced) ones get tripped up between topical/grammatical categories, one using the lang code and one using the full name. (Thank you EP and others for correcting the mistakes). I would prefer helping out the user and retro-fitting all templates to accept the lang code and place the entry in the correct category (like {{infl}}). Would other agree? --Bequw → ¢ • τ 18:41, 5 May 2008 (UTC)

How about including something like this (pseudocode) in each template? If {{{lang}}} is on this list (of two- and three-character codes), then read it as a language code; otherwise, read it as a language name. That is the user-friendliest solution imo.—msh210℠ 18:50, 5 May 2008 (UTC)

I've already proposed dual behaviour at Template talk:plural of#lang= parameter accepting ISO 639 code some time ago. The only possible problem would be when there's two or three-letter language name that differs from it's ISO code, but the only two examples I can think of (Lao and Ido) don't do that. Ideally, if there are no drawbacks, this would be incorporated into {{language}} itself (the template that does ISO code -> language name conversion), so that it works transparently on the templates that already use it. --Ivan Štambuk 19:23, 5 May 2008 (UTC)

Ewe, the language, has codes ewe and ee; I don't know which we use. {{{lang}}} or {{language}} or whatever can assume that anything in lowercase matching an entry on the list of codes is a code, and anything containing uppercase or not matching an item on the list is a name. No?—msh210℠ 19:44, 5 May 2008 (UTC)

Both are valed, so algorithm would expand e.g. {{ewe}} or {{lang:ewe}} to Ewe, not to something else. Two-letter codes don't collide with language names, so all of the two-letter codes would be expanded to proper language name. Te point is to first check whether there is the template name with the passed value of lang, if not, then treat it as language name and not as ISO code. So suppose Ewe had -3 code 'abc' and someone did lang=abc, and there's another language called just that - "abc", there'll be no way to distinguish those.

I don't think that making some predefined list would be scalable enough, given that there are thousands of ISO codes (both ISO 639-2 and -3), the new ones are being defined every once in a while, and that still many of them are not present in the Template: namespace to be used by {infl} and others. The trick of checking the first letter for uppercase/lowercase sounds good, but wouldn't account for cases where users mistype language name in lowercase (not that there are many of those...probably none ^_^). --Ivan Štambuk 20:37, 5 May 2008 (UTC)

This code works, IMX: {{#ifexist:{{language|{{{lang}}}}}|{{language|{{{lang}}}}}|{{{lang}}}}}. I think this should only be used for legacy templates where we want to keep language-name support, though; I think we're much better off using language codes across the board. -- Visviva 23:42, 5 May 2008 (UTC)

If this is to be implemented inside {language}, and thus have this dual behaviour being propagated to all the other templates that use {language} to generate language name out of their own's lang= parameter, it shouldn't suppose to call itself, right?--Ivan Štambuk 14:50, 6 May 2008 (UTC)

I think that adding this feature to {{language}} would be a very bad move. If people start adding the full language name then we suddenly have two problems, firstly people could misspell the language name (not that much of a problem as it's easy to fix and quite noticeable with red categories), secondly people can easily add the wrong name for a language. For example the recent West Frisian/Frisian divide. If the name of the language has to be typed manually it is entirely possible that they'll put Frisian where we want West Frisian - I'm sure there are similar situations with other languages (like Norwegian ;). It also makes the syntax more complicated as it is more varied. The language codes are neat and easily understandable, so I would much prefer to deprecate all instances where the full language name is being passed. Conrad.Irwin 14:59, 6 May 2008 (UTC)

If people use misspelled/wrong/obsolete language names they would got red categories too (try using lang=Frisian now that there's no Category:Frisian language).

It's exactly the same thing if all the templates like {plural of} that support lang=<full language name> would be extended with Visviva's above snippet (how many of them are there anyway?), or if they called newly written {language} itself and let it take care of it transparently. It's just that the latter solution is more elegant ;)

{plural of} is used on tens of thousands of pages, and it's support for full language name is not going away anytime soon. It should be handled one way or another.

More varied syntax will hopefully force a number of templates that just expand {{{lang}}} to be rewritten to call {language} properly, and just forget about this issue altogether.

I do agree that full language names should be considered deprecated behaviour for lang=, for the most prominent reason of when there are multiple English names for the same language ("Slovene" vs. "Slovenian" and similar). --Ivan Štambuk 15:36, 6 May 2008 (UTC)

It hadn't occurred to me that this would be implemented in {{language}}. I don't think that would be wise -- if name2code functionality is even workable, it should be in a separate template for reasons of maintainability, elegance, and those situations where people want to use the code2lang functionality of {{language}} specifically. I was just thinking of this as a backwards-compatibility patch for the various older templates that still require the full language name, and which nobody feels much like going around and fixing. -- Visviva 16:13, 6 May 2008 (UTC)

Ivan, I wouldn't consider full language names to be deprecated. The problem we run into is that some languages do not have an ISO code, but we do have entries for them. This is most noticeable among the Australian Aboriginal languages. There are some situations where a full language name is preferred, albeit in a minority of cases. --EncycloPetey 16:19, 6 May 2008 (UTC)

Good point; recently I poked Robert Ullmann about this issue of languages that don't have ISO codes (especially historical ones - e.g. Old Polish), and that therefore cannot be used with {infl}, {etyl}, all the templates that support lang= (including all context labels). So I guess until that is resolved we're not going anywhere towards the goal of standardising upon ISO codes..

But ideally, once this is resolved, lang= would always accept ISO codes and the templates themselves would decide whether to expand them into language names or not, for the purposes of categorization. --Ivan Štambuk 16:57, 6 May 2008 (UTC)

Where we deal in languages that have no ISO code, would it be of benefit for us to devise a non-conflicting code for our own purposes that could be easily converted to an ISO code when/if one is assigned? Perhaps something like Wplo for old Polish, as an example. Thryduulf 17:40, 6 May 2008 (UTC)

The ISO standards includes rules for creating internal use codes so that they'll be consistent and non-conflicting. We might want to assemble a list of languages for which no code exists, but for which Wiktionary has need of one. Then we can figure out the codes we want to use all at once, instead of piecemeal. --EncycloPetey 19:44, 6 May 2008 (UTC)

+1. —Ruakh_TALK 00:04, 7 May 2008 (UTC)

Making a central place to put this pseudo-codes sounds like a good idea. Possibly incorporating proposals from the discussion at WT:BP#CFI for languages, to make sure that some dialects on conlangs don't get suddenly promoted more than their deserve. --Ivan Štambuk 01:27, 7 May 2008 (UTC)

Do the ISO standards for language codes include the notion of the "x-" prefix like a lot of other such standards? If so, we could assign our own private codes until such time as a real code becomes available. Mike Dillon 02:14, 7 May 2008 (UTC)

Yes, and what's more, they include the notion of a non-initial -x- to separate standard subtags from private-use subtags (so that e.g. en-US-x-Illinois-Chicago means "some privately recognized form of U.S. English"). The W3C i18n article "Language tags in HTML and XML" is a good introduction to the structure and use of modern language tags; BCP 47, currently RFC 4646, is a more official document about them. —Ruakh_TALK 03:00, 7 May 2008 (UTC)

As a starting point I've created Wiktionary:Languages without ISO codes initially as a place to collate the languages that need codes and then to become a reference to the codes we generate. I've added all the languages from WT:ETY/TEMP that don't have codes, but there are more than likely others that need to be added. Thryduulf 10:11, 7 May 2008 (UTC)

The ISO standards do not include x- or -x-; that is the IETF extensions for using tags (not codes) in HTML etc. ISO provides for codes starting with "q"; but not enough for out purposes. WMF uses codes extended from an ISO -1 or -3 code, e.g. fiu-vro. Note that we do not pass our language codes as HTML script tags, we explicitly use a set of script templates and classes. The x- or -x- convention does not apply. What we need is to add codes as WMF does, using a -1 or -3 code with an extension, e.g. for Old Polish use "pl-old" (or whatever). The WMF language committee does this, but only when they need the code for a new wikipedia, so we we need more of our own, they should then be documented somewhere where other wikts can use them if desired. Robert Ullmann 12:42, 7 May 2008 (UTC)

As an interim solution, we could redirect Template:lang:English to Template:lang:en, Template:lang:French to Template:lang:fr, and so on. Then we can switch these templates to expect language codes with no problem. (Perhaps Robert would be willing to have AF gradually replace all the language-names-as-codes with the right codes?) —Ruakh_TALK 00:02, 7 May 2008 (UTC)

I've implemented an interim solution at {{fullLanguage}} which is now being used in {{plural of}}. This allows using the language codes without breaking support for the full language names, though I think we should not add support for full language names to templates that currently only accept the codes. Conrad.Irwin 10:05, 7 May 2008 (UTC)

Um, I updated {{langname}} (which was using a massive switch ;-). Was going to to this last night. The problem with {fullLanguage} is that it creates a huge number of references to Template:English (and lang:English) and relies on that template not existing. Not too good. It also calls the language templates needed or not.

I set up {langname} to use the fact that all codes are lc, and all language names contain at least one uc letter; I think this is good as it doesn't "cover for" various errors. {plural of} can then use {{langname|{{{lang|English}}}}} and it won't reference {language} or the en or en:lang templates in the default case. I think this is better? And we don't need to be in too much of a hurry to eradicate uses of the full name. Robert Ullmann 13:42, 7 May 2008 (UTC)

Earlier, I had made a list of templates that use {{{English|lang}}}. Could we retrofit them, like we did to {{plural of}}? List: {{third-person singular of}}, {{past of}}, {{present participle of}}, {{alternative spelling of}}, {{past participle of}}, {{comparative of}}, {{simple past of}}, {{superlative of}}, {{gerund of}}, {{IPA Rhymes}}, {{contraction of}}, {{irregular simple past of}}, {{apocopic form of}}, {{alternative form of}}, {{alternative capitalization of}}. --Bequw → ¢ • τ 19:54, 7 May 2008 (UTC)

Yes, a good idea. But I would suggest letting it sit for at least a few days or so while we look at it. Then we might add rules to AF to convert lang=(recognized language) to lang=(code) ... but not force a transition, taking care for occasional editors and so on. While still continuing to allow exceptions; exception are not bad, they tell us what we may need to extend. Robert Ullmann 23:32, 7 May 2008 (UTC)

Gentium is the second font choice for all Cyrillic-alphabet languages, not just Russian. Gentium should be removed, because it only supports Russian, and is lacking characters required for almost every other language.

Specifically, it appears in the font list for class="RU" in MediaWiki:Common.css, and in template:Russian fonts , which is used in template:Cyrl.

Lucida Grande, the big Mac Unicode font, also installed on Windows with Safari, could also be added to these font specs, probably before Code2000 which is a serif font, and not very attractive.

And is there any reason not to move the template to an accurate name, like template:Cyrillic fonts or template:Cyrl fonts, and start transitioning the CSS class name to .Cyrl in place of .RU? —Michael Z. 2008-05-05 17:51 z

This illustrates why we shouldn't force any fonts on our readers. For everyone apart from IE 6 and down the browser will automatically find the closest matching font for any character. I have removed the use of {{Russian fonts}} from {{Cyrl}} and have removed "Gentium" from the font list for old browsers. Conrad.Irwin 15:23, 6 May 2008 (UTC)

Thanks.

I agree that it's usually best not to mess with the display in non-broken browsers, especially when we have class names assigned to allow customization. —Michael Z. 2008-05-06 17:48 z

Unicode, does some wonderful work. Not only do they provide code-points for all our characters, but also the Unicode Collation Algorithm (UCA) for sorting and the Common Locale Data Repository for locale info. But Unicode makes certain trade-offs in their works. When dealing with text, they favor rule-based approaches that are *mostly* correct and don't meddle too much in specific words that are exceptions. One example is their work on Text Segmentation, which lays out what code-point sequences constitute user-expected letters are (e.g. the Spanish digraph 'ch' or the Hungarian trigraph 'dzs' are single letters in those locales). Unicode takes a rule-based approach, with no dictionary of exceptions, and in ambiguous situation doesn't always get it right. In Hungarian, könnyű is spelled 'k'ö'ny'ny'ű' (due to contraction on the digraphs) whereas tizennyolc is spelled 't'i'z'e'n'ny'o'l'c'. Hyphenation, as defined by their Line Breaking Algorithm, is another area. They take this rule-based approach for several reasons, to limit the scope of their work, to make their algorithms more efficient, etc. Providing the list of exceptions is "beyond the scope" of their projects. But, it's probably not beyond the scope of our project. We at Wiktionary would seem to have a wonderful opportunity to help provide a more complete solution, by creating and maintaining banks of exceptions to the algorithms that Unicode (and possibly others) provide. Two projects that spring to mind are:

1) To provide explicit spellings for words that Unicode's algorithm parse incorrectly.

2) To provide hyphenation information for words. We already do this to some extent. Unicode doesn't define very much how to hyphenate inside a word, so we could outline language specific algorithms and word-specific exceptions. (TeX's hyphenation algorithm is a good one starting point for English.)_{This appears infeasible. TeX's algorithm doesn't use pre-existing rules, it derives thousands of "patterns" from an existing hyphenation dictionary, just to save space. --Bequw → ¢ • τ 19:30, 7 May 2008 (UTC)}

I'm sure that are other ways we can augment the information about languages that Unicode and others provide. Eventually we could provide ways to extract this information from Wiktionary to help text-processing systems that can spare a bit of RAM/CPU to consult a dictionary. Any other ideas, or has this been discussed before and I'm late to the party? --Bequw → ¢ • τ 20:21, 5 May 2008 (UTC)

This is an interesting idea, we could perhaps have something like {{sort as|k|ö|ny|ny|ű}} - though I'm not sure which section this would be best to put it in, though that doesn't really matter. It should probably be as a Note of some kind near the bottom. We already seem to have {{hyphenation|co|incid|ence}} - so feel free to use it - though perhaps a region parameter should be added for I am aware that US and UK hyphenate same things differently Hyphenation: prog‧ress vs. Hyphenation: pro‧gress. If we wanted to have an Appendix:English hyphenation or any other language for that matter, I'm sure we could - though I don't know who could write it. Conrad.Irwin 18:44, 6 May 2008 (UTC)

I've made {{collate as}}. The name isn't great as the information could be used for other purposes besides collating, but a name like {spelled as} seems unclear. For now I've put it in the ===Usage Notes=== section. See dzsungel for an example. --Bequw → ¢ • τ 19:30, 7 May 2008 (UTC)

Does this have to be visible to the user? I accidentally deleted your template from tizennyolc because I did not realize what it was for and I was working on standardizing Hungarian numbers. Your idea could be tested with the code Conrad used a while ago to build the Hungarian index. --Panda10 12:30, 8 May 2008 (UTC)

See the newly formed Wiktionary:Project - Text Processing Information (and please help). --Bequw → ¢ • τ 05:26, 29 May 2008 (UTC)

Either something was broken recently, or someone that loves parenthesis is pushing them again. I have "hide maximal parenthesis" checked (and others) but usually they appear for qualifiers. What gives? --Connel MacKenzie 08:11, 6 May 2008 (UTC)

WT:PREF was reset recently, presumably by accident. -- Visviva 09:15, 6 May 2008 (UTC)

Is it just me, or when I type in ] it expands it to ] during the save process? Conrad.Irwin 16:36, 8 May 2008 (UTC)

(test: hinder )

Yes, it is during the save process (like subst and ~~~~. It removes the first xxx: string, and anything in parens at the end. They call it the "pipe trick". meta:Help:Piped link#Pipe trick Robert Ullmann 17:36, 8 May 2008 (UTC)

I thought that previously the wikitext was left unaltered -maybe I just never paid enough attention before. Conrad.Irwin 17:42, 8 May 2008 (UTC)

Putting brackets in {{masculine plural of}} and {{feminine plural of}} produces odd results; see novias and novios. These are templates that should be compatible with brackets in the parameter, since they may be the only definition line text. Can someone fix them up? Dmcdevit·t 07:35, 14 May 2008 (UTC)

Fixed. (I don't understand what those entries are trying to say — either (deprecated template usage) novios and (deprecated template usage) novias are the plurals of (deprecated template usage) novio and (deprecated template usage) novia, respectively, or they're the masculine and feminine plurals, respectively, of (deprecated template usage) novio, and I don't think it works to split the difference this way — but either way I agree that argument-bracketability is a requirement for these templates.) —Ruakh_TALK 23:53, 14 May 2008 (UTC)

I've made an initial proposal to add a parameter to all inflection templates, italicize=yes, which identifies foreign terms that are usually italicized, italicizes the term, and adds a category. Please review and comment at WT:BP#Foreign terms. —Michael Z. 2008-05-14 19:34 z

I understand, based on the BP discussion, that this parameter would be added to English-language inflection templates, not those of other languages. It could also be added to form-of templates, if the BP discussion so decides.—msh210℠ 19:42, 14 May 2008 (UTC)

I'm just thinking about whether that is possible. It may be useful to identify and categorize foreign terms in every language, and might even be doable, but the convention of italicizing should probably only be used in English words. —Michael Z. 2008-05-14 20:01 z

I think we should use the convention of the language that is using the foreign term, e.g. for an English term used in French we should follow the French convention, etc. Thryduulf 20:10, 14 May 2008 (UTC)

There may be some issues.

1. It will be a long time until we can establish what these conventions are for the 100+ languages represented. Some may not have such a convention. In the meantime, we should either have a neutral convention to represent this for every occurrence (like a context tag or a symbol), or simply make use of the category and not indicate this in the entry.
2. I'm hesistant to inject foreign editorial conventions into en.Wiktionary. This is an English-language document which refers to many foreign terms, but not a multilingual document. It may be okay to observe normal foreign orthography even if it's not understood by English-language readers, as long as it doesn't add confusing, contrasting, or clashing conventions.
3. I think it would have to be considered case-by-case, for these reasons.

Do you know what the convention is for French or any other language? Perhaps we could use italics in other languages which do so, although many scripts simply don't have italics. I'd prefer not to add e.g., a mix of «guillemets», « spaced guillemets » , and small caps to various headwords. —Michael Z. 2008-05-14 20:50 z

I'm proposing a clear definition of the distinction between regional English language, and regional topics. This would slightly change the way regional context templates are used, and clearly separate language categories such as Canadian English from regional topics such as Canada. Please review and comment at WT:BP#Regional language vs regional topics. —Michael Z. 2008-05-14 19:39 z

Created this template. Purpose: Meta-template to support consistent, default-hidden, bulleted lists of the words in a small semantic set. Example: {{press events list}}. Please use, modify, improve, ignore, or delete, as appropriate. -- Visviva 05:47, 17 May 2008 (UTC)

Having wanted to use this without having to use its very odd syntax (at Barack) I have fixed it:

• Language is lang=(code) as with other templates. It used to have 3rd parameter "lc:", with the ":" included.
• Origin is from=(language). It used to be 2nd parameter, with "from" included: ...|from Greek|...
• Documented or= and gender= which were already there.
• Corrected documentation that said extra |'s were required at the end, which of course they are not.

The old forms still work, as I haven't updated any pages at all. This would be a good bot run is we can ever get a new XML dump. Robert Ullmann 14:48, 17 May 2008 (UTC)

There seems to be something (minor) wrong with it; Barack has a stray space. —Ruakh_TALK 16:45, 17 May 2008 (UTC)

Just so: a stray space before the noinclude tag. (And thanks to Stephen for the Arabic forms ;-) Robert Ullmann 23:10, 17 May 2008 (UTC) (Ullmann kicks himself, having known perfectly well where Mubarak comes from, but not once making the connection!) Robert Ullmann 23:13, 17 May 2008 (UTC)

I've added a couple of rules to AF to change parameters. (with one very bad false start, see history for Agnes if you like; I'll blame it on being 3AM). Please do comment. No hurry. Robert Ullmann 01:10, 18 May 2008 (UTC)

Wiktionary:Statistics is now over two months old. Does anyone other than Connel know how to update it? SemperBlotto 21:44, 17 May 2008 (UTC)

WE NEED a new XML dump! (*sigh* will try to ask if Brion can fix it will let someone fix it or we will create a dyn mirror or something else that is atrocious because—Ullmann fails at creating an half-way impressive run-on sentence) Robert Ullmann 23:07, 17 May 2008 (UTC)

You might ask Connel if he's taken action already on this. I had noted this problem to Connel directly a few weeks ago, and he cited the problem with the XML dump. It is possible he has set something in motion in the meantime. --EncycloPetey 02:06, 18 May 2008 (UTC)

Now updated by Connel. SemperBlotto 21:21, 22 May 2008 (UTC)

Is it just me or has anyone else been experiencing painfully slow response times working with Wiktionary over the last day or so? If it's not just me, does anyone know what's going on? -- WikiPedant 19:23, 22 May 2008 (UTC)

Not too bad for me, East Coast US. XML dumps? DCDuring TALK 19:30, 22 May 2008 (UTC)

Its much slower than Wikipedia t open pages for edit - I work mainly in Microsoft ^Internet^ Explorer, via DSL. Each time I hit the "edit" button it takes about 40-60 seconds to pull up the page. I notice it is 2-3 times faster if I go to the library so maybe my configuration. Can someone technical can give advice, such as recommended browser, and Windows configurations? Goldenrowley 01:37, 27 May 2008 (UTC)

I used to use IE7. Had problems, including freezing when trying to refresh. I switched to Firefox and get better overall performance by a bit and no freezing on refresh. We really need for Wiktionary to work better for IE so we can not discourage potential recruits. DCDuring TALK 01:43, 27 May 2008 (UTC)

Thanks for the tip... I will try switching to Firefox! Goldenrowley 02:01, 27 May 2008 (UTC) OMG that makes such a HUGE difference in speed I have already done three edits, and its like 10 times faster!! .... you would think the browser would not be so important.Goldenrowley 02:14, 27 May 2008 (UTC)

Whatever was going on when I made the original posting in this section has cleared up. My response times are back to normal (at least normal for Wiktionary). I too use Firefox 98% of the time. For me, Firefox doesn't seem any faster than IE, but it is reputed to be much less vulnerable to spyware, adware, and assorted malware. In general, Wiktionary is known to be slower than many other sites on the web (apparently, resource problems on the WT mothership). Goldenrowley, your library computers are likely faster simply because, like the networks at many institutions, they are plugged into bigger bandwith commercial lines than we normal folks can get at home with DSL (the computers at my university workplace are also much faster on the web than my DSL-connected home computer). -- WikiPedant 02:37, 27 May 2008 (UTC)

"Anglo Saxon" should be hyphenated in the "in other languages" links in the left margin. Any idea how to fix this? — Paul G 09:45, 23 May 2008 (UTC)

Why should it say "Anglo-Saxon" at all? That's neither the native name of the language nor the standard modern term for it (which is "Old English"). --EncycloPetey 17:31, 23 May 2008 (UTC)

At any rate, that isn't something Wiktionary-specific. Those language names are uniform across all Wikimedia projects. I think you'd have to file a bug report on Bugzilla to get a developer to change it. Angr 13:33, 25 May 2008 (UTC)

Thanks for that. I reported it and it's now been fixed. — Paul G 08:52, 28 May 2008 (UTC)

For some reason, {{PL:pedia}} generates:

• Template:projectlink

instead of

• Template:projectlink

The same is true of

• {{PL:quote}}
• {{PL:source}}
• {{PL:doesn't exist}}

I assume this is something to do with the prefix being a sister-project interwiki link. Is this intentional to stop people using them in deference to {{projectlink}} or do we actually need to fix this before further software changes break it worse? Conrad.Irwin 10:05, 23 May 2008 (UTC)

I'm guessing neither: it probably wasn't intentional (since, who cares if you use {{PL:pedia}} instead of {{pedialite}} or {{projectlink|pedia}}?), but it probably isn't a problem, either (since, who cares if you can't use {{PL:pedia}} instead of {{pedialite}} or {{projectlink|pedia}}?) —Ruakh_TALK 12:19, 23 May 2008 (UTC)

It's treated as a cross-wiki transclusion by MediaWiki. There is a flag to control whether that functionality works and it's turned off for WMF wikis. Mike Dillon 14:31, 23 May 2008 (UTC)

Cross-wiki transclusion... wow... how do we get that turned on? -- Visviva 13:02, 25 May 2008 (UTC)

Well, we'd have to convince someone to turn on $wgEnableScaryTranscluding and and go set iw_trans on the interwikis we wanted it to work for. I expect that would be a hard case to win :) Mike Dillon 20:44, 25 May 2008 (UTC)

The PL: templates are all subtemplates; they should not be used directly on a page. Either use {{projectlink}} or use {{pedialite}} and so on. It wasn't intentional, but there was no intent that the PL: templates be anything other than subtemplates shared between projectlink/projectlinks/pedialite/sourcelite, etc etc. Robert Ullmann 23:50, 25 May 2008 (UTC)

On the mudra page to templates presently in the top right corner of the page overwrite each other. I attempted to fix this by using the code from w:Template:Clear to no avail. __meco 09:50, 25 May 2008 (UTC)

{{wikipedia}} seems to be misbehaving; when moved down below the TOC it overwrote the definition text. I adopted a low-tech solution; feel free to revert. -- Visviva 13:01, 25 May 2008 (UTC)

{{wikipedia}} should always be inside the language section it structurally refers to (i.e. the English section for the default). The horrible "cosmetic fix" of putting it above the English header if there were enough sections to cause a TOC was because no-one treated the wandering links as a bug, and got them fixed.

Stack whatever templates/images for a language immediately after the language header, and it will render fine. When you find an entry that was corrupted by someone trying to "fix" it, just put it back the way it should be, in the section it belongs to. Robert Ullmann 00:06, 26 May 2008 (UTC)

In Firefox 2.0.0.14, with right-floating TOC, the pediabox is still partially overwriting definition text. This does not occur in Opera. This is the same behavior I mentioned in the TOC discussion earlier; I'm clueless as to the cause. (maybe just an FF bug?) -- Visviva 02:13, 26 May 2008 (UTC)

Right-floating TOC will break lots of things; if you want to use it for yourself okay, but you'll have to put up with it. Robert Ullmann 21:46, 27 May 2008 (UTC)

Actually this is the only problem I've seen so far. I wouldn't switch back for the world... but still don't understand why the pediabox is behaving this way. -- Visviva 00:16, 28 May 2008 (UTC)

I'm not sure what you're saying. :-/   If you're suggesting that right-floating elements (using class="floatright", or — in the case of the TOC — copying the .floatright CSS) don't interact properly with the beginning of a language section, then surely that's something that needs to be fixed? Even if everything is structurally in the right language section, sometimes it will extend for some users into the beginning of the next one. —Ruakh_TALK 01:49, 28 May 2008 (UTC)

I suppose mudra was not a good example, but IMO most entries that have {{wikipedia}} should have {{pedialite}}, because they are about words that do not map neatly onto a single concept. "Mudra" is a bad example of this because although it has two senses, these are both covered in the linked article. Where a word refers only to a specific encyclopedic concept, it may make sense to give prominent billing to WP, just as WP gives prominent billing to Wiktionary on entries that are about specific words as such. But in most cases the link should be relegated to "See also," just as the corresponding link would be on the pedia. -- Visviva 02:13, 26 May 2008 (UTC)

I've been around on Wiktionary for a long time, but I've never worked out what the links <lang>:<headword> (for example, ] on the page for normal) are for. I'm guessing they are place-holders for missing entries in the specified language on that page - is this right? (The power of posting... it had not occurred to me that this is what they might be for until I started writing this question.) — Paul G 08:19, 31 May 2008 (UTC)

Those are the interwiki links, allowing users to see the same entry in other language wiktionaries. -Atelaes λάλει ἐμοί 08:26, 31 May 2008 (UTC)

That is the code that creates the interwiki links that appear on the left-hand side of the entry page. --EncycloPetey 20:10, 31 May 2008 (UTC)

Oh, I see. Thanks for that. — Paul G 09:22, 3 June 2008 (UTC)