Template talk:ux
Add topic194.249.247.164 08:23, 17 October 2016 (UTC) in tr (transliteration) change letter 'x' to 'h'.
Text direction rtl doesn't work on mobile display version on iPad and iPhone
[edit]On an iPad or iPhone, compare for יופי: the Hebrew example phrases are displayed in the desktop site version https://en.wiktionary.org/wiki/יופי correctly, with the final punctuation mark on the left end of the phrase: למה? – but are displayed incorrectly in the mobile site version https://en.m.wiktionary.org/wiki/יופי, with the final punctuation mark on the right end of the phrase: למה? — This unsigned comment was added by Dan Pelleg (talk • contribs) at 20:04, 23 January 2017.
- Some CSS attributes somehow don't make it into the mobile version. I'm not sure why. --WikiTiki89 20:14, 23 January 2017 (UTC)
- hmm. Just saw that another attribute that is cancelled is the increased font size defined by the <big> -tag. So if this problem isn't specific to this template, where do you go with it? Dan Pelleg (talk) 01:27, 26 January 2017 (UTC)
- I think it's a known issue, but maybe the developers don't know about it. You can try reporting it at https://phabricator.wikimedia.org/ (you can log in with your Wikimedia account). --WikiTiki89 16:05, 26 January 2017 (UTC)
- @Wikitiki89 The problem is that the mobile version does not load MediaWiki:Common.css (it uses MediaWiki:Mobile.css instead) so the css rule which specifies RTL for Hebrew does not apply. A workaround would be to inline the direction markers in the generated HTML (by passing RTL to
tag_text
). The best solution would be to share some CSS between desktop and mobile. – Jberkel (talk) 15:24, 21 February 2017 (UTC)- So that's what it is. Most of MediaWiki:Common.css is intended to be used everywhere. If that's not the case, then we need to create a new shared CSS page that will be. --WikiTiki89 16:00, 21 February 2017 (UTC)
- @Wikitiki89 Yes, let's create a new CSS page. Do you want to kick off a discussion in the BP or GP to get some feedback? – Jberkel (talk) 18:43, 21 February 2017 (UTC)
- Can we use the @import CSS statement to avoid duplication? Would that use too many resources? DTLHS (talk) 18:51, 21 February 2017 (UTC)
- That was already the plan (or something like that). If there is nothing in MediaWiki:Common.css that can't be applied to mobile pages, then we don't even need to create a new page. But I'm worried there might be, so we should put all the general code on separate page and include that one in both desktop and mobile pages (however it is that we do that, whether or not it is with the @import statement). --WikiTiki89 18:58, 21 February 2017 (UTC)
- @Wikitiki89 If you want to see how it looks when MediaWiki:Common.css gets applied to the mobile skin, add
@import url(/w/load.php?debug=true&lang=en&modules=site.styles&only=styles);
to your local minerva.css. Hebrew text direction works as expected but some details are a bit off. It might therefore make sense to extract all shared style definitions into a new CSS file. – Jberkel (talk) 15:01, 22 February 2017 (UTC)
- @Wikitiki89 If you want to see how it looks when MediaWiki:Common.css gets applied to the mobile skin, add
- That was already the plan (or something like that). If there is nothing in MediaWiki:Common.css that can't be applied to mobile pages, then we don't even need to create a new page. But I'm worried there might be, so we should put all the general code on separate page and include that one in both desktop and mobile pages (however it is that we do that, whether or not it is with the @import statement). --WikiTiki89 18:58, 21 February 2017 (UTC)
- Can we use the @import CSS statement to avoid duplication? Would that use too many resources? DTLHS (talk) 18:51, 21 February 2017 (UTC)
- @Wikitiki89 Yes, let's create a new CSS page. Do you want to kick off a discussion in the BP or GP to get some feedback? – Jberkel (talk) 18:43, 21 February 2017 (UTC)
- So that's what it is. Most of MediaWiki:Common.css is intended to be used everywhere. If that's not the case, then we need to create a new shared CSS page that will be. --WikiTiki89 16:00, 21 February 2017 (UTC)
- @Wikitiki89 The problem is that the mobile version does not load MediaWiki:Common.css (it uses MediaWiki:Mobile.css instead) so the css rule which specifies RTL for Hebrew does not apply. A workaround would be to inline the direction markers in the generated HTML (by passing RTL to
- I think it's a known issue, but maybe the developers don't know about it. You can try reporting it at https://phabricator.wikimedia.org/ (you can log in with your Wikimedia account). --WikiTiki89 16:05, 26 January 2017 (UTC)
The following discussion has been moved from Wiktionary:Requests for moves, mergers and splits (permalink).
This discussion is no longer live and is left here as an archive. Please do not modify this conversation, but feel free to discuss its conclusions.
Now that the older {{usex}}
has been orphaned for a while, I think its name should again be the primary name for this template. It's much clearer than {{ux}}
. {{ux}}
would remain as a redirect of course. —CodeCat 15:42, 15 August 2016 (UTC)
- Sounds good to me. —Aɴɢʀ (talk) 18:21, 15 August 2016 (UTC)
- Support. --WikiTiki89 20:39, 15 August 2016 (UTC)
- Me too. DCDuring TALK 21:52, 15 August 2016 (UTC)
- OK with me. Benwing2 (talk) 00:30, 16 August 2016 (UTC)
- Me too. DCDuring TALK 21:52, 15 August 2016 (UTC)
- Support. --WikiTiki89 20:39, 15 August 2016 (UTC)
- With me, that's now six in favour and none against. — I.S.M.E.T.A. 16:20, 18 August 2016 (UTC)
- Oppose. A vote decided that ux should be the name used in the wiki markup, not usex. Usex is not particularly clear either; use-example would be. The template has a documentation that should help clarity; the name itself as used in the wiki text was decided to be short. --Dan Polansky (talk) 16:46, 23 August 2016 (UTC)
- Furthermore, the old code of template usex should be kept to make revision histories legible. The practice of the recklessness toward legibility of revision histories has to stop. --Dan Polansky (talk) 16:55, 23 August 2016 (UTC)
- I mean, if all this is about is having a legible primary name, why not rename to
{{use-example}}
? Why make the page histories that use{{usex}}
less legible? --Dan Polansky (talk) 17:01, 23 August 2016 (UTC) - For reference, the vote is Wiktionary:Votes/2015-11/term → m; context → label; usex → ux. Votes are high-profile exercises in collecting evidence for consensus. --Dan Polansky (talk) 17:08, 23 August 2016 (UTC)
- Nowhere in that vote is there any implication that people prefer the name "ux". In fact, the vote appears set up specifically for three templates which have three equivalent templates differing only in their parameters. Therefore, it's very reasonable to conclude most people voted for the parameter change, not the name. This RFM discussion, which shows a clear consensus in favour of treating the two names equivalently and preferring
{{usex}}
, is additional evidence for that viewpoint. —CodeCat 17:14, 23 August 2016 (UTC)- The above claim that the vote is not about the name ux is ridiculous. If you want usex to become the dominant name in the wiki text, please set up a vote. The linked vote gives authorization to bots to automatically replace
{{usex}}
with{{ux}}
. This low-profile RFM cannot be used to replace a vote since RFMs are so much more low-profile than votes. Furthermore, I originally understood this RFM to want to proceed on an analogy to{{label}}
vs.{{lb}}
, where{{lb}}
is the predominant markup used in the wiki text even though the primary name is{{label}}
; and therefore, I do not see the above supports are being for{{usex}}
being the primary name to be seen in the actual wikitext. Either way, a high-profile vote cannot be overriden by a low-profile RFM with unclear change proposal. --Dan Polansky (talk) 17:20, 23 August 2016 (UTC)- That it's unclear to you is not anyone else's problem. The people who voted understood it well enough to vote in favour of it. —CodeCat 17:23, 23 August 2016 (UTC)
- In any case, RFM cannot override a fairly recent high-profile vote.
- On a further note, currently running Wiktionary:Votes/2016-07/borrowing, borrowed, loan, loanword → bor is only about the name and not about the template arguments, yet shows a large majority 9:5 support the short name. I submit to the reader that the recent votes showed support for very short names, including
{{m}}
. I don't believe editors at large want to see{{mention}}
directly in the mainspace. --Dan Polansky (talk) 17:27, 23 August 2016 (UTC)- CodeCat, there's no evidence that your reasoning applies to all people who voted at "usex → ux". You are acting like you can read their minds. You may want to create a new vote. --Daniel Carrero (talk) 17:30, 23 August 2016 (UTC)
- Dan Polansky, please check Wiktionary:Votes/2016-07/borrowing, borrowed, loan, loanword → bor again. The vote is about template name and arguments. --Daniel Carrero (talk) 17:32, 23 August 2016 (UTC)
- I created Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup. I don't know what else to do. --Dan Polansky (talk) 17:36, 23 August 2016 (UTC)
- I think this was a good idea. --Daniel Carrero (talk) 18:02, 23 August 2016 (UTC)
- I created Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup. I don't know what else to do. --Dan Polansky (talk) 17:36, 23 August 2016 (UTC)
- Dan Polansky, please check Wiktionary:Votes/2016-07/borrowing, borrowed, loan, loanword → bor again. The vote is about template name and arguments. --Daniel Carrero (talk) 17:32, 23 August 2016 (UTC)
- CodeCat, there's no evidence that your reasoning applies to all people who voted at "usex → ux". You are acting like you can read their minds. You may want to create a new vote. --Daniel Carrero (talk) 17:30, 23 August 2016 (UTC)
- That it's unclear to you is not anyone else's problem. The people who voted understood it well enough to vote in favour of it. —CodeCat 17:23, 23 August 2016 (UTC)
- The above claim that the vote is not about the name ux is ridiculous. If you want usex to become the dominant name in the wiki text, please set up a vote. The linked vote gives authorization to bots to automatically replace
- Nowhere in that vote is there any implication that people prefer the name "ux". In fact, the vote appears set up specifically for three templates which have three equivalent templates differing only in their parameters. Therefore, it's very reasonable to conclude most people voted for the parameter change, not the name. This RFM discussion, which shows a clear consensus in favour of treating the two names equivalently and preferring
- Support move. - -sche (discuss) 16:58, 23 August 2016 (UTC)
- @- -sche: How do you address my points and concerns? What is the benefit of
{{usex}}
over{{use-example}}
or{{usage-example}}
? --Dan Polansky (talk) 17:02, 23 August 2016 (UTC)- We regularly refer to usage examples as "usexes" (singular: "a usex") in discussions, so that name is clear, whereas "ux" is not. "Usage-example" is too long to use in entries, although we do sometimes use full words for template names, and so making "usage-example" the full name and using "usex" and "ux" as redirects in entries would be OK, but "usex" is also OK and evidently has more support, and fits with other templates and modules that don't use full words (e.g. the "translit" templates and modules which, aside from any other debate they are subject to, are named with the short form "translit" and not "transliteration"). Legibility of revision histories is not a goal of mine; meeting it would be too much of a hindrance to progress, constricting our ability to improve template and module code. - -sche (discuss) 17:17, 23 August 2016 (UTC)
- @- -sche: How do you address my points and concerns? What is the benefit of
- Oppose: I'd support redirecting
{{ux}}
to{{usage example}}
, while keeping{{ux}}
in all entries. - This idea (using an abbreviation in the entries, the abbreviation being a redirect to a template with a long name) would be in line with
{{der}}
->{{derived}}
,{{m}}
->{{mention}}
, etc. - By the way, before someone suggests editing all entries by bot to make them use
{{usex}}
, this 1-week, half-dozen people RFM discussion should not overrule a 1-month, 19-people vote (by "19 people", I mean only in the "usex → ux" part). - I'd rather use
{{eg}}
(a new, unvoted redirect) when creating new examples, but I wouldn't change all entries to accomodate that, except by creating a new vote. --Daniel Carrero (talk) 17:16, 23 August 2016 (UTC) - Since there's still a large majority in favour of the move, I will make it yet again. —CodeCat 18:25, 1 September 2016 (UTC)
@-sche, Angr, Wikitiki89, DCDuring, Benwing2, I'm so meta even this acronym I've tried repeatedly to make this change, but it keeps getting reverted by Dan. We have over 2/3 in support in this RFM, so is Dan going against consensus? —CodeCat 23:09, 2 September 2016 (UTC)
- As I said, low-profile RFM should not override a vote that we already had in which ux seemingly, but not according to CodeCat, was chosen. Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup is going to clarify the thing I believe. --Dan Polansky (talk) 23:11, 2 September 2016 (UTC)
- And you, a single person, decide that? Against 7 that disagree? —CodeCat 23:13, 2 September 2016 (UTC)
- I don't understand the question. I think it is a matter of general principle that low-profile RFM does not override a recent vote. It is the matter of bringing the thing to the proper radar screen, the proposal being phrased in clear terms. That has happened in Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup, the vote is running, and the vote is going to show consensus in this matter via a proper channel. --Dan Polansky (talk)
- A bare majority (3-2) with only six voting is no endorsement, certainly neither consensus nor a high level of participation. I don't see that it was accurately closed, as there was no consensus. Such a bare majority would have been sufficient had the matter been decided where it belonged, but as the wrong venue was chosen, our stricter standard of 2/3 applied.
- There are been more participants in this RFM. The matter never merited a policy vote to begin with. The vote was analogous to a special law, often a hallmark of a representation system manipulated by professional parliamentarians in real politics. DCDuring TALK 00:00, 3 September 2016 (UTC)
- The vote is still ongoing. Scheduled end date: September 28. --Daniel Carrero (talk) 00:14, 3 September 2016 (UTC)
- OK, there appears to be a lot of confusion here. CodeCat is proposing that the page named
{{ux}}
be a redirect to{{usex}}
but that we keep using{{ux}}
in actual markup, as the previous vote agreed to. This is similar to the situation that we have with{{m}}
and{{mention}}
, and{{l}}
and{{link}}
, where (e.g.){{m}}
is a redirect to{{mention}}
but{{m}}
is the form used in most markup. IMO this situation is rather confusing, but it's consistent with what's been done before. On the other hand, Dan's vote (if I'm not mistaken) seems to be proposing that we bot-rename{{ux}}
to{{usex}}
in all 26,000+ pages using it, which would go against the recently-established vote to rename things the other way. I'm not sure whether this difference was intentional on Dan's part or due to confusion, but it should be rectified some how or other. Benwing2 (talk) 20:29, 3 September 2016 (UTC)- I was one of those confused. I would think we would want to robo-convert all instances of
{{ux}}
to{{usex}}
so that contributors saw{{usex}}
in the edit window. I would think this would reduce the need to find the templates documentation and reduce the number of folks who abandoned their attempt to contribute. If{{usex}}
is to be the default template after operation of the bot, then it should be the name of a real template, not a redirect to the real template. - The general principle of having slightly longer, somewhat more explanatory names, using standard abbreviations where possible, would apply to all such cases. But it is hard to find a name that explains why and for what we use
{{l}}
and{{m}}
, so we could leave them as is. — This unsigned comment was added by DCDuring (talk • contribs).- This isn't a dispute over the spelling of the template- it's a dispute over the content of
{{usex}}
. CodeCat wants to replace it with the content of{{ux}}
, but Dan wants to keep the old version of{{usex}}
for backwards compatibility. Perhaps we could add code so that the new version could detect parameters consistent with the old version and make them work, while putting them in a cleanup category. That way we can keep the old-version edits under control in current entries, but those in edit histories won't be effected. - Such a strategy is easier to do in this case because the two are mutually exclusive and can't be confused: either the language code is the first parameter or it's
|lang=
, and the translation is either the third parameter or|t=
. There are a few entries where{{usex}}
was recently added. When CodeCat made her change, they showed up in Cat:E, so I changed the parameters. Then Dan undid the change, and they ended up in Cat:E again. I don't mind changing them back one more time (I prefer the new version), but let's leave it at that. Chuck Entz (talk) 21:15, 3 September 2016 (UTC)
- This isn't a dispute over the spelling of the template- it's a dispute over the content of
- I was one of those confused. I would think we would want to robo-convert all instances of
- OK, there appears to be a lot of confusion here. CodeCat is proposing that the page named
- The vote is still ongoing. Scheduled end date: September 28. --Daniel Carrero (talk) 00:14, 3 September 2016 (UTC)
- I don't understand the question. I think it is a matter of general principle that low-profile RFM does not override a recent vote. It is the matter of bringing the thing to the proper radar screen, the proposal being phrased in clear terms. That has happened in Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup, the vote is running, and the vote is going to show consensus in this matter via a proper channel. --Dan Polansky (talk)
- And you, a single person, decide that? Against 7 that disagree? —CodeCat 23:13, 2 September 2016 (UTC)
- (outdent) As for "CodeCat is proposing that the page named
{{ux}}
be a redirect to{{usex}}
but that we keep using{{ux}}
in actual markup", that's what I thought until it seemed that it was CodeCat themselves who claimed otherwise, and then claimed "That it's unclear to you is not anyone else's problem". Frankly, this RFM appears ambiguous and too likely to mislead and confuse the participants, and it should be scrapped because of the lack of clarity of what it really proposes that we do. The vote Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup does not have that clarity or unambiguity problem. --Dan Polansky (talk) 04:30, 4 September 2016 (UTC)- If CodeCat thought that mainspace was still to carry
{{ux}}
, and this is only about where the code should be located, why not go for{{usage-example}}
since that is not going to be in the wiki code in the mainspace? I can't see how this discussion is anything but confusing. --Dan Polansky (talk) 04:35, 4 September 2016 (UTC) - FYI, Wiktionary:Votes/2016-08/Making usex the primary name in the wiki markup now has 10 participants. --Dan Polansky (talk) 04:40, 4 September 2016 (UTC)
- If CodeCat thought that mainspace was still to carry
- Since the vote is over and didn't address the actual matter of this RFM (it addressed only the wiki markup of entries, not the templates themselves), can someone please perform the move?
{{usex}}
is now a redirect to{{ux}}
, but this RFM's consensus calls for{{ux}}
to be moved to{{usex}}
and become a redirect instead. —CodeCat 18:41, 1 October 2016 (UTC)
- All that is true, but who cares really? * Kept for general apathy. --Genecioso (talk) 22:22, 4 June 2018 (UTC)|
No categorisation
[edit]@Benwing2 Seems like the categorisation isn't working anymore. See ṭuppum — Fenakhay (حيطي · مساهماتي) 08:30, 1 August 2023 (UTC)
Needs a |notrans= field
[edit]for entries where an English translation is pointless, as with usage examples of names. — LlywelynII 10:01, 4 August 2023 (UTC)
ref parameter
[edit]@Benwing2: Regarding the reference parameter, please clarify which "originating external site" the description refers to. Chealer (talk) 05:55, 4 December 2024 (UTC)
- @Chealer I don't really know what this means. The purpose of references in general is to provide sources for information that may be contested or questioned, especially if it's hard to verify (such as for an obscure language) or might be challenged (e.g. for a reconstruction). If the information is easily verifiable it may be easier to provide a "Further reading" section for the entire entry with the appropriate source(s). If the usage example is actually a quotation from some external site, you should not use
{{ux}}
or any variant, but instead use{{quote-book}}
,{{quote-journal}}
,{{quote-web}}
or the like and provide the bibliographic information about where the quote came from. Benwing2 (talk) 01:05, 8 December 2024 (UTC)- @Benwing2: I understand the role of references in general, but not in this template. Could you at least provide a couple example calls to
{{ux}}
which properly useref
? Chealer (talk) 02:05, 8 December 2024 (UTC)
- @Benwing2: I understand the role of references in general, but not in this template. Could you at least provide a couple example calls to