Template talk:usex

Deletion debate

The following information passed a request for deletion.

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

---

Template:usex

Does this actually do anything useful? --Yair rand (talk) 11:04, 6 December 2010 (UTC)

IMO yes. For one it allows us to keep track of usexes with Special:WhatLinksHere/Template:usex, furthermore it allows for transliteration and translation. And I think a few other things. So for purely personal reasons, keep. Mglovesfun (talk) 11:08, 6 December 2010 (UTC)

It doesn't shorten the amount that has to be typed for transliteration and translation, or for regular usexes, and tracking usexes with WhatLinksHere is ineffective so long as this template isn't in widespread use. If this does accomplish something useful, we should have a bot add it to all usexes. Otherwise, I can't see any reason to keep it. --Yair rand (talk) 11:15, 6 December 2010 (UTC)

It's of a (very) limited usefulness, that I don't deny. It does regularize all usexes, that is makes them all the same when it's used. Not sure the "should be used for every usex, or deleted" argument is the greatest in the world, after all, {{en-noun}} isn't used for every English noun, but I wouldn't want it to be deleted. Mglovesfun (talk) 11:18, 6 December 2010 (UTC)

Keep. When the transliterator starts working, it will require usexes to be in a template. --Vahag 14:53, 6 December 2010 (UTC)

True. So keep, with the understanding that there's no reason to use this on not-to-be-transliterated (or on manually-transliterated) usexes.​—msh210℠ (talk) 18:12, 6 December 2010 (UTC)

Keep. It is useful for standardizing, i.e., regularizing, format. Perhaps it could be given span-class tags, similarly as for Template:m, Template:f and Template:n. —AugPi 02:49, 8 December 2010 (UTC)

I can't see how a non-standard template can be used for standardizing... --Yair rand (talk) 03:53, 8 December 2010 (UTC)

What do you mean by "non-standard template"? Anyway, another reason (to keep): it can be used to compactify a usex into a single line, even the same line as the definition: see, e.g., http://en.wiktionary.org/w/index.php?title=okupi&action=edit . —AugPi 05:51, 8 December 2010 (UTC)

There you see six lines which have been collapsed into two. —AugPi 05:52, 8 December 2010 (UTC)

If the community supports using this template in those situations, we should have a bot add it to all such entries. If it to be used on usexes in automatically transliterated languages then it should be removed from other languages and bot-added to autotransliteratable language usexes once the transliterator extension starts working. Otherwise it is a huge mess contributing to non-standardization, with most examples using one format and a few examples using this template. --Yair rand (talk) 06:26, 8 December 2010 (UTC)

That makes it clear... so if Template:usex passes RFDO, then the issue of its standardization should be brought up in the Beer Parlour... —AugPi 06:42, 8 December 2010 (UTC)

Keep. It is useful for standardizing. We have quite a lot of different USEX formating now. Users probably don't know about the policy, or try to promote their idea on how USEX should look like, or maybe this is due to historic reasons? Anyway a template can help to standardize the format and make future changes much easier. Matthias Buchmeier 18:16, 8 December 2010 (UTC)

Kept, nice strong consensus. Mglovesfun (talk) 12:25, 20 December 2010 (UTC)

Transliteration not showing up?

In Арманистон:

1. Armenia

   Арманистон яке аз кишварҳои Осиё ва Аврупо аст.

   Armaniston jake az kišvarhoi Osiyo va Avrupo ast.

   (please add an English translation of this usage example)

The transliteration only appears when a translation is added. DTLHS (talk) 00:55, 10 July 2013 (UTC)

inline parameter gone?

No inline:

1. vse je zaman

   it's all in vain

With inline:

1. vse je zaman ― it's all in vain

The translation disappears in the second example, please fix. "inline" is used. --Anatoli ^{(обсудить}/^вклад) 07:22, 10 July 2013 (UTC)

Fixed- I had thought it was the transliteration that was supposed to be displayed. DTLHS (talk) 07:25, 10 July 2013 (UTC)

Thank you. --Anatoli ^{(обсудить}/^вклад) 07:31, 10 July 2013 (UTC)

transliteration hidden when inline=1

I disagree with hiding the transliteration when inline=1. The transliteration and translation usually can fit on one line, as in շուն#Old Armenian. If they can't, then inline=1 shouldn't be used. Can this be fixed please? --Vahag (talk) 14:55, 11 July 2013 (UTC)

I just copied the behavior from the earlier code, so yes if that's what is desired that can happen. DTLHS (talk) 14:56, 11 July 2013 (UTC)

Yes, I wanted a new behavior. Thanks for making it happen. --Vahag (talk) 15:02, 11 July 2013 (UTC)

feature request: missing translations should categorize

Often the editors only provide usage example without a translation, meaning that the t= parameter would be blank (or missing completely). In such cases it would be great if the template would categorize in some category, e.g. "Xxx entries with missing translations in usage examples", so that the editors that are more conversant with English (or the original editors themselves) could look them up later in fill in the t= appropriately. --Ivan Štambuk (talk) 11:59, 14 July 2013 (UTC)

Since lang isn't mandatory (do we want to make it mandatory?) it could only be used when lang is specified and lang≠en. Mglovesfun (talk) 12:00, 14 July 2013 (UTC)

Yep. On second thought, I think that in case of all FL usexes translations should be made mandatory, and some kind of stub message should be shown, similar to {{rfdef}} This usage example needs a translation. Please help out and add a translation. I often find myself unable to think of the translation of various idiomatic and semi-idiomatic usages of a word, so I skip such usex altogether. This kind of message would be ugly but would incentivize editors and occasional knowledgeable users. --Ivan Štambuk (talk) 12:18, 14 July 2013 (UTC)

•  Implemented by DTLHS Many thanks! --Ivan Štambuk (talk) 23:07, 14 July 2013 (UTC)

Good feature, thanks. I have added an English translation to German "erfahren" when it turned up in Category:Translation requests (German). --Anatoli ^{(обсудить}/^вклад) 23:20, 14 July 2013 (UTC)

Please fix this

I just had to remove the usex templates from an article because they were causing problems:

https://en.wiktionary.org/w/index.php?title=picture&diff=21419121&oldid=21403603

Fixed. DTLHS (talk) 20:56, 14 July 2013 (UTC)

муравей

There are some issues with the template, I don't understand, please take a look at муравей. The transliteration and the translation are displayed but not the original Russian script. --Anatoli ^{(обсудить}/^вклад) 12:28, 30 July 2013 (UTC)

You need to do this. But those are not usexes. They are quotations and should be formatted according to Wiktionary:QUOTE. --Vahag (talk) 12:34, 30 July 2013 (UTC)

Default to inline style?

It seems like this is mostly used with the inline parameter on. Would it make sense to default to inline and use a different parameter for the expanded form? DTLHS (talk) 01:33, 9 August 2013 (UTC)

I think so, yes. --Vahag (talk) 05:21, 9 August 2013 (UTC)

Sounds good to me. Also, is possible to have support for show/hide usexes like we do for inflections, or add collapsability, in case their number grows too large? --Ivan Štambuk (talk) 06:10, 9 August 2013 (UTC)

auto-italicized transliteration

Discussion moved from Module talk:usex.

Could this be modified so that it does not italicize the transliteration when lang=ja? That was the behavior until recently. Thanks --Haplology (talk) 16:54, 27 September 2013 (UTC)

Has Wiktionary:Votes/2007-08/Layout of example sentences for Japanese entries been obsoleted? —Ruakh_TALK 20:51, 27 September 2013 (UTC)

Wow, I've actually never seen that vote before. Looks like some of it has, but that's a lot of material to look over. In any case relevant part has not. The format in the vote is the format I want usex to use, and which usex did use until a few days ago. In the vote, as now, the transliteration consists of a line of kana not in italics and followed by a line of romanized Japanese which is italicized. Basically kana is never italicized and italicized Japanese looks bizarre, and the use of kana itself corresponds to the use of italics in Latin scripts, that is to show how something is read. --Haplology (talk) 05:11, 28 September 2013 (UTC)

Oh, I see, I didn't realize that there were Japanese entries using the "transliteration" parameter to hold (what I see as) two separate fields — a kana transcription (which shouldn't be italicized) and a romanization (which should) — with manual formatting to make it come out right. Sorry about that. I think we should fix those entries — their current approach is total template abuse, and it would be much better to give this template a kana parameter (which would also apply appropriate script markup) — but for now, your proposed fix (not italicizing when lang=ja) is a good temporary measure. I'll do that now. —Ruakh_TALK 06:00, 28 September 2013 (UTC)

Translations have a similar "abuse" of templates w.r.t. Japanese, so if we add a kana parameter here we should also add one to Module:translations. DTLHS (talk) 02:35, 30 September 2013 (UTC)

That's a good point, but with translation-templates I think the situation is a bit different, because as I understand it, there the hiragana version is conceptually a full-fledged translation, more like how for Serbo-Croatian we present translations in both Cyrillic and Latin scripts. (Please correct me if I'm wrong about that.) With the example sentences, the hiragana version is clearly subordinate, since the headword is in kanji, so only the kanji version is actually using the headword; the fact that we supply a hiragana version is a peculiarity of our handling of Japanese, and not like anything we do for any other language. So kana= seems like a simple solution to a small problem. But with translations, we have a messy and complicated situation that applies to a lot of languages, so adding kana= just for Japanese seems like a bit of a dirty hack. I dunno. (To be clear: I absolutely agree that the current approach is a dirty hack, too, but I'm just not so excited about migrating from one dirty hack to another.) —Ruakh_TALK 03:28, 30 September 2013 (UTC)

Definitely. If we want to remain as language agnostic as possible in general templates like this one and t, maybe we could just add a second transliteration parameter and use the script detection module to determine whether or not to italicize. DTLHS (talk) 03:42, 30 September 2013 (UTC)

I'm not sure that would really be language-agnostic: true, nothing in the template would explicitly refer to ja, but if the functionality is only used for Japanese, and is designed based on the requirements of Japanese, then it's essentially Japanese-specific logic. (Specifically: you're suggesting that "transliteration" be used both for a secondary native-script rendering, where it would be tagged as the same language as the original, and for a Latin-script romanization, where it would be italicized and not language-tagged. That logic makes sense for Japanese kanji usage examples, but not for Japanese translations, and possibly not for anything else.) Also, BTW, this is a smaller point, but I'm not sure about your reference to "the script detection module". AFAIK, the only currently-extant function answering to that description is detect_script in Module:utilities, which isn't fit to this purpose. So if we want to use that approach, we'd have to either enhance that function or create a new one. —Ruakh_TALK 18:57, 30 September 2013 (UTC)

Why is it not fit for this purpose? —CodeCat 19:06, 30 September 2013 (UTC)

For languages that have only a single script, it returns that script without checking text. Even for languages with multiple scripts, it basically assumes that the text will be in one of those scripts; it currently has a fallback check to just try all scripts, but that fallback is marked with TODO: This is slow; we really shouldn't be doing this!, so presumably we shouldn't be adding new code that depends on it, especially in templates like the {{t}} family that are used bajillions of times per page. (As it happens, ja is mapped to both Jpan and Latn, so we can trick the function into telling us what we want by simply pretending the language is always ja; but obviously that's not how the function is intended to be used, and it also doesn't achieve the language-agnosticism that DTLHS was hoping for.) —Ruakh_TALK 00:47, 1 October 2013 (UTC)

Inline depending on text length

Inline is really best used for short pieces of text. So is it possible to make this decision automatically, by looking at the length of the given text? Below a certain threshold length it can make it inline, above it it doesn't. —CodeCat 03:26, 7 October 2013 (UTC)

I'm a bit worried about the rapidness of changes of the template. It sounds OK to me but I've been using inline (0 or 1) just in case of them becomes default. I don't like the idea making them collapsed by default, BTW. --Anatoli ^{(обсудить}/^вклад) 03:44, 7 October 2013 (UTC)

I guess. We should probably take various screen widths into account when deciding what the threshold is. Also it should be possible to override if necessary. DTLHS (talk) 03:45, 7 October 2013 (UTC)

If the idea is that very short examples should always be inline, long examples should be multiline, and in-between examples can go either way, then we can probably develop a decent heuristic that implements that, especially if we add language-specific information to Module:languages and/or script-specific information to Module:scripts. But is it worth it? I suspect that there's a lot of editor-to-editor variation in deciding whether to make a given example inline, and I'm not sure this is something that benefits from standardization. —Ruakh_TALK 05:02, 7 October 2013 (UTC)

Is boldface not supported in transliterations again?

See [[біда]]. Boldface "біда́" is transliterated as ʺʺʺbidáʺʺʺ. --Anatoli ^{(обсудить}/^вклад) 03:47, 8 October 2013 (UTC)

It appears to be a problem with the uk-translit module. Compare: біда біда (bida bida), біда біда (bida bida)

Because the module has ["'"]='ʺ' as a rule. I'm not sure how to fix this. DTLHS (talk) 04:18, 8 October 2013 (UTC)

Thank you, I didn't realise this was the reason. I wondered why Mzajac (talk • contribs) made it so. This has to go. ["'"] should be just ["'"], unchanged. --Anatoli ^{(обсудить}/^вклад) 04:25, 8 October 2013 (UTC)

There are other Cyrillic (and perhaps other) transliteration modules like this- be-translit for one. DTLHS (talk) 04:27, 8 October 2013 (UTC)

Ah, thanks again. In Belarusian too, "'" is used like a letter instead of Russian ъ or "separation" ь (to make a sound /j/ between consonant and the following vowel). I don't think there should be other modules but let me know if you find any. --Anatoli ^{(обсудить}/^вклад) 04:33, 8 October 2013 (UTC)

audio

If possible, it would be nice to have a more compact display of play button, when audio file is available for the usex. See audio#Latin. --Ivan Štambuk (talk) 22:23, 21 November 2013 (UTC)

That would probably require some new css classes / javascript, you might be better off asking in the grease pit. DTLHS (talk) 23:13, 21 November 2013 (UTC)

Author, year, work, page

Often attested citations are used as usexes, and it would be good to display their metadata within this template, without resorting to manual wiki markup. Perhaps at the very beginning, formatted in small font, with year boldfaced, and ref= parameter wikilinking the work if provided? --Ivan Štambuk (talk) 15:15, 8 December 2013 (UTC)

User:Atelaes is cooking something here. Maybe we should see how it tastes before we expand {{usex}}'s functionality. --Vahag (talk) 16:08, 8 December 2013 (UTC)

I've still got some features to add, a lot of content to add to the data page(s), and some minor bugs to work out, but it's done enough that you can sample it. It's in use at κάθημαι (káthēmai). -Atelaes λάλει ἐμοί 20:07, 8 December 2013 (UTC)

Also, it's really just meant to mirror the functionality of {{grc-cite}}, simply with an infrastructure which is an order of magnitude easier to expand and maintain, and specifically designed to be used in any language. -Atelaes λάλει ἐμοί 20:11, 8 December 2013 (UTC)

Attested citations should not be formatted as usexes. If this is "often" done, then I guess we have a lot of cleanup to do. :-)   —Ruakh_TALK 22:39, 8 December 2013 (UTC)

Why not? Attestations are primarily to make sure that the word/meaning exist. Often, the most illustrative usexes can be found in attested works. It's much easier to translate existing usexes than to make up your own. --Ivan Štambuk (talk) 23:01, 8 December 2013 (UTC)

Yes, I agree. That's why I object to automatic hiding of all quotations, and why I object to the notion that we should always have usexes even when we already have citations that serve the same purpose. It's still not a good reason for re-formatting citations as though they were made-up examples. —Ruakh_TALK 23:27, 8 December 2013 (UTC)

Indeed. It would be nice to have unified usage examples / quotations, with the only difference being a toggle to hide or show each one. DTLHS (talk) 23:33, 8 December 2013 (UTC)

inline parameter is not working

See 구별#Verb. The example sentence, transliteration and translation all appear on the same line. --Anatoli ^{(обсудить}/^вклад) 22:54, 15 January 2014 (UTC)

bug Ruakh about it, I can no longer edit the module. DTLHS (talk) 03:55, 16 January 2014 (UTC)

The inline parameter is "on" when its value is not empty. "0" also counts as not empty. You need to use either "inline=" with no value, or just leave it out. —CodeCat 14:01, 16 January 2014 (UTC)

What dash?

Shouldn't the em dash used be a quotation dash instead? My impression is that that's usually used to separate sentences in opposition to one another. (Lines 83 & 86 in the current version of the module.)​—msh210℠ (talk) 18:35, 11 May 2014 (UTC)

Done.​—msh210℠ (talk) 20:15, 4 August 2014 (UTC)

Delinking of transliterations

Can someone PLEASE delink transliterations? Wiktionary:Grease_pit/2014/May#Transliteration_linked_to_individual_parts_in_usexes_when_hyperlinked, Wiktionary:Beer_parlour/2014/July#Example_sentences_in_ELE.2C_linking_of_words_and_delinking_of_transliterations --Anatoli ^{(обсудить}/^вклад) 00:33, 14 July 2014 (UTC)

Keeping the old code

The old code of template usex should be kept to make revision histories legible. --Dan Polansky (talk) 16:54, 23 August 2016 (UTC)

Literal translation

Could literal translations be enabled for {{usex}}? The usex_t function in Module:usex/templates lists "lit" as a parameter, but does not do anything with it. I do not have the expertise to fix this myself. — Eru·tuon 22:08, 9 January 2017 (UTC)

@Erutuon How should it be formatted? DTLHS (talk) 22:12, 9 January 2017 (UTC)

@DTLHS Not totally sure. How about this? — Eru·tuon 22:30, 9 January 2017 (UTC)

• كُتُب وَطُرُود وَأَوْرَاق‎

  kutub wa-ṭurūd wa-ʾawrāq

  books, parcels, and papers

  (literally, “books and parcels and papers”)

• كُتُب وَطُرُود وَأَوْرَاق‎ ― kutub wa-ṭurūd wa-ʾawrāq ― books, parcels, and papers ― literally, “books and parcels and papers”

Done. DTLHS (talk) 22:44, 9 January 2017 (UTC)

Thanks! — Eru·tuon 00:34, 10 January 2017 (UTC)

Category:usex with multiple transliterations

Shouldn't we remove this? --Z 09:49, 16 March 2017 (UTC)

Tests

@Erutuon Please check/adapt the testcases when you make changes to the modules, I just fixed a bunch of things. Thanks! – Jberkel (talk) 15:46, 24 April 2017 (UTC)

@Jberkel: I'm sorry, I can't figure out where these testcases are that you're talking about. Could you direct me to them? — Eru·tuon 20:42, 24 April 2017 (UTC)

Oh, I see, at Module:usex/testcases. — Eru·tuon 20:45, 24 April 2017 (UTC)

RFM discussion: August 2016–June 2018

See Template talk:ux#RFM discussion: August 2016–June 2018.