Template talk:Native name

This template was considered for deletion on 2011 December 24. The result of the discussion was "keep".

Archives

This page has archives. Sections older than 730 days may be automatically archived by when more than 5 sections are present.

needless error when blanks

{{Native name list}} gives needless error when a pair is empty/absent, and the optional |italics2=no is set.

OK:

Guten tag1 (German)
Bonjour (French)

blank/abs: ..|tag2=|name2=|italics2=no

Guten tag1 (German)

-DePiep (talk) 08:48, 7 November 2022 (UTC)[reply]

Fixed in the sandbox. The proposed code now ignores any parameter# unless there is a corresponding tag# or name#. In addition, the numbers no longer need to be contiguous: editors can leave gaps, e.g.:

{{native name list/sandbox|tag1=de|name1=Guten tag|tag15=fr|name15=Bonjour|tag23432=ja|name23432=こんにちは}} produces

Guten tag (German)
Bonjour (French)
こんにちは (Japanese)

@Trappist the Monk: could you take a look at my changes before I make them go live? I also added testcases: Template:Native name/testcases and Template:Native name list/testcases — hike395 (talk) 01:48, 8 November 2022 (UTC)[reply]

Wow that's great (I was not sure it ER was needed, just a warning in the documentation). Also thx for the number-skip-option. DePiep (talk) 04:36, 8 November 2022 (UTC)[reply]

Error message when all input is blank?

Feature question. When no pairs are entered at all (all blanks), the template returns an error. Is that a good feature? For example, when automating this in an infobox, this requires to test for any input beforehand ("IF any tagN, nameN present THEN apply {native name list} ELSE do not call it"). That means testing |tag1, name1, ..., tag23432, name23432= for input.

{native name list/sandbox|tag1=|name1=|tag2=|name2=} →

Error {{native name list}}: list is empty (help)

This requires adding an if-test: {{#if:{{{tag1|}}}{{{tag2|}}}{{{name1|}}}{{{name2|}}}...|{native name list|tag1={{{tag1|}}}|name1={{{name1|}}}|...} }

DePiep (talk) 05:26, 8 November 2022 (UTC)[reply]

Thanks for adding testcases to Template:Native name list/testcases! That's quite helpful.

I went ahead and removed the blank list error message from the sandbox: it returns an empty string now. PTAL at the test cases.

Shall we go live? — hike395 (talk) 11:42, 8 November 2022 (UTC)[reply]

Great! About going live: I did not check each rest thoroughly; I liked your idea to ask User:Trappist the monk for another glance at the code. No hurry for me. DePiep (talk) 12:11, 8 November 2022 (UTC)[reply]

No technical issues with the change though philosophically I'm not so comfortable. Empty unused parameters are clutter which is something that editors often complain about. So, when I wrote this module I intentionally wrote it to emit an error message when the template contained empty unused parameters – editors are more accepting if this kind of error messaging is implemented in a new template from the beginning than they are when the error messaging is retrofitted onto an existing widely-used template. It's the all-of-a-sudden-lots-of-error-messages syndrome.

Apparently the only example implementing {{native name list}} inside an infobox template is {{infobox currency}}. Why is it done that way instead of how it is done in other infoboxen where {{native name list}} is the rvalue in a infobox parameter assignment? I think that the empty-list error message has value because it tells the editor that something is obviously missing. If {{native name list}} must be inside the infobox code then perhaps there is a better way to suppress the empty-list error message than the brute-force method currently employed by the module sandbox: |_suppress_empty_error=yes or some such.

—Trappist the monk (talk) 14:39, 8 November 2022 (UTC)[reply]

suppress_empty_error=yes I understand and is an other solution for the issue I pointed out. Omit the unserscore btw: a regular parameter not in-module. (btw, I do not accept the anytext-construct that would effectuate |suppress=no as a yes).

For the rest, I do not understand any of this philosophy. For starters, this change will not "retrofit ... all-of-a-sudden-lots-of-error-messages": the contrary, when implemented other-things-unchanged it suppresses floods of error messages (if currenly present at all).

Maybe it helps if I decribe the situation. (1) parameter pairs like |tag2, name2= must be complete or an error message is due anywhere anytime. (2) But optional parameters like |italics3=no are not an error when unused (unused because of pair3 being). This change is welcome. (4) Situation "all pairs empty" is not an error status: a pair is optional, so the first one is too. We're talking about a warning at best. I welcome this change; as said, the switch parameter is OK too (especially for in-infobox usge).

I do not understand the "complaints" of "empty-parameter-clutter". Yes lots of ewmpty parameters appear, but where is it complained? I've never heard a complaint. Is it by article-editors? Template-editors like us? I've adjusted lots of documentations to provide full/most-used parameter code lists. Anyway, as an Inconvenience is subordinate to errors and warnings, and defeinitely not redmessage-worthy.

Then, I reject the "why must it be done this way?" about (my) incorporating {{Native name list}} in an infobox. (To state the obvious, it is to standardise style & presentation over the transclusions, and to simplify article-editors input). Noone claimed a "must". Also, I don't like the tone that is suggesting I did something wrong without being able or clear describing what.

TL;DR: add the one parameter (adjusted), otherwise accept changes. DePiep (talk) 21:00, 8 November 2022 (UTC)[reply]

I generally follow the robustness principle when writing software, which is "conservative in what you do, liberal in what you accept". I prefer not to subject editors (or readers) to red error messages, unless the markup is truly broken.

I'm not sure what to name the "turn off the empty list error" parameter, given DePiep's objection, above? — hike395 (talk) 04:35, 9 November 2022 (UTC)[reply]

Fiat & trust. Name is up to you (IMO prefix "_" is common & helpful in Lua for nonpublic names, but less so in our templates where that distinction does not exist; also needless confusing for non-tech article editors). I hope you can reward my suggestion to _not_ encode the boolean as "any input will set the parameter to yes" (|suppress_empty_error=no → True

). Have a nice edit. DePiep (talk) 05:42, 9 November 2022 (UTC)[reply]

I'm a big fan of Module:Yesno, so I wouldn't treat "no" as "yes" (the robustness principle in action). — hike395 (talk) 05:59, 9 November 2022 (UTC)[reply]

Done --- I chose to implement |empty_list_error=, where an explicit "no" (or "n" or "0" or similar) will turn off the error message. Still in sandbox, not yet live. — hike395 (talk) 06:24, 9 November 2022 (UTC)[reply]

FYI, {{Infobox currency/sandbox}} & its {{/testcases}} implementations show no surprises before/after. Some 150 tc's in mainspace. I'll keep an eye on them anyway, should you go live. DePiep (talk) 08:16, 9 November 2022 (UTC)[reply]

I chose |_suppress_empty_error=yes because that says what the parameter/value pair does when present in the template. I included the leading underscore as an indicator that it isn't a parameter that should be used except in special cases, inside of an enclosing template for example, where general editors don't have access to {{native name list}}. |empty_list_error=yes, |empty_list_error=no? What do those mean to a user? Make a list? Don't make a list?

—Trappist the monk (talk) 12:59, 9 November 2022 (UTC)[reply]

I tend to dislike double negatives, because they can be confusing. For example, I'm still not 100% sure whether DePiep thinks that |suppress_empty_error=no should mean to print an error message or not to print an error message (I'm assuming it would print an error message: it's a double negative).

To avoid the double negative, I phrased it as a positive. The empty list error message is "on" by default. When a negative argument is given to the "empty_list_error" parameter, it turns off the message. It seems clearer to me. — hike395 (talk) 16:15, 9 November 2022 (UTC)[reply]

I think that what was not desired was a parameter that takes any value as a directive to do the action. So |_supress_empty_error=no (or any other value the doesn't equate to yes) actually suppressing the error message is not desired. Your alternative parameter |empty_list_error=yes does not express an action; it is not an instruction to the template to do something so it would be better as |supress_empty_list_error=yes or |ignore_empty_list_error=yes which reads like a directive to control the template output. I think that suppress is better than ignore in this case because we are directing the template to mute the error message (so that we may ignore it).

—Trappist the monk (talk) 18:02, 9 November 2022 (UTC)[reply]

To clarify: I asked that that parameter not be encodeded so that any nonblank input would count as a Yes. Example of bad: with {{collapse top}}, |expand= does the same action for both |expand=yes and |expand=no ??? ("Any value will have this effect"). One of the two is wrong, and must be prevented by code (not by documentation). DePiep (talk) 02:52, 10 November 2022 (UTC)[reply]

Ttm: "(or any other value the doesn't equate to yes)": make that: "... as handled by {{Yesno}} or module:yesno" (read T/F, uc/lc, ..). Be explicit in documentation, also about a default if present. DePiep (talk) 03:03, 10 November 2022 (UTC)[reply]

How about |empty_list_is_error= ? — hike395 (talk) 23:33, 9 November 2022 (UTC)[reply]

What is it about |supress_empty_list_error=yes that you cannot stomach? For |empty_list_is_error= the default is yes so to mute the error message |empty_list_is_error=no. I'm not sure that a negative value (no) is as 'assertive' as a positive (yes) value. And |empty_list_is_error= isn't really a directive; for someone just reading the template invoke, what does |empty_list_is_error=yes really mean? How does the template respond to that parameter? I think that |supress_empty_list_error=yes more clearly indicates to this unfamiliar reader how the template will respond. Yeah, the reader should also read the template documentation, but will they?

—Trappist the monk (talk) 00:39, 10 November 2022 (UTC)[reply]

OK, changed the parameter to |suppress_empty_list_error=, and changed its sense (i.e., "no" means make an error, "no" is default). Updated the test cases. Shall I make the sandbox live? — hike395 (talk) 02:41, 10 November 2022 (UTC)[reply]

I support. Agree that the double-neg is undesired, but the situation is inherited. DePiep (talk) 03:05, 10 November 2022 (UTC)[reply]

Trappist the monk, your language here is needlessly attacking/judgemental/dismissive, and prevents good understanding & solving the questions at hand. It expects or even requires others to mentally rewrite your post into somthing on-content, which could lead to extra mistakes & misunderstandings. I see no context that could justify this. Already noted this earlier, above. DePiep (talk) 02:58, 10 November 2022 (UTC)[reply]

Wait wait: the single-pair-version {{native name}} can have the very same new parameter (say |empty_list_is_error=) with exactly the same functionalities :-) @Hike395 and Trappist the monk:. -DePiep (talk) 08:28, 10 November 2022 (UTC)[reply]
I am used to writing Pythonic APIs. In those APIs, if you accept a list, then it's fine to silently return an empty list when given an empty list. But if you accept a singleton of some sort, then it's fine to complain if it is empty/nil/None.

Unless you have a specific infobox application in mind, I would suggest always throwing an error for empty {{native name}}. But if you are thinking of something specific, please do say more! — hike395 (talk) 20:50, 10 November 2022 (UTC)[reply]

Later -- I see that Trappist already changed {{native name}} per you suggestion. That's fine, too. — hike395 (talk) 20:53, 10 November 2022 (UTC)[reply]

@Hike395 and Trappist the monk: May I expect the sandbox to go live? Or, needs more checking? -DePiep (talk) 10:24, 14 November 2022 (UTC)[reply]

Looks good to me! — hike395 (talk) 16:10, 14 November 2022 (UTC)[reply]

~~::We never made this go live. I can merge the old edit into the latest module. — hike395 (talk) 14:10, 27 May 2023 (UTC)~~[reply]

plainlist

I've recently made an adjustment to use Module:List out of a desire to limit the "exposed surface" of the plainlist class (see API design), which will soon be TemplateStyled (see MediaWiki talk:Common.css/to do#Plainlist). See this diff for the changes. All the test cases I checked were green, but the comment "to avoid replacement count contaminating the output" (which I believe to be no longer relevant since we are no longer gsubbing) gave me pause on deploying. Izno (talk) 03:13, 8 December 2022 (UTC)[reply]

Your changes look good to me. — hike395 (talk) 10:15, 8 December 2022 (UTC)[reply]

Tweaked the sandbox; don't need to table.concat() a sequence that has only one member. Because the live version wraps each sequence member in <li>...</li> tags, for the case of only one language, the module uses string.gsub() to remove those tags. string.gsub() returns two values: the string (modified or not) and a count of the number of replacements that were made. If the module returns the result from a string.gsub() operation, the calling template gets both return values. To prevent that, assigning the result from a string.gsub() operation to a single local variable and then returning that variable prevents the extraneous count from being returned to the calling template.

—Trappist the monk (talk) 16:23, 8 December 2022 (UTC)[reply]

Yeah, I had considered removing the concat, and was pretty sure that was what was going on with gsub. Cool. Izno (talk) 17:57, 8 December 2022 (UTC)[reply]

sh-Cyrl, sh-Latn, sr-Cyrl, sr-Latn

Could it be adapted so the above show 'Serbo-Croatian Cyrillic', 'Serbo-Croatian Latin', 'Serbian Cyrillic' and 'Serbian Latin' respectively, just like {{lang-sh-Cyrl}}, {{lang-sh-Latn}}, {{lang-sr-Cyrl}} and {{lang-sr-Latn}} do? –Vipz (talk) 12:51, 20 March 2023 (UTC)[reply]

Link target

Hello. Would it be possible to add support to define a different target from the text shown? For example, in my case in Slovene Wikipedia I would like to show 'francosko' (French, adverb) and link to 'francoščina' which is the name of the language. The IANA languages table translations are all adverbs in my case. I guess it would be handy to be able to link to another target in the English Wikipedia too. --TadejM ^{my talk} 07:13, 26 May 2023 (UTC)[reply]

Doesn't that already happen? At sl.wiki, you would like to show 'francosko':

{{native name|fr|text|link=yes}} → ''text'' ([[francosko]]) → text (francosko)

and, at sl.wiki, you want the displayed name 'francosko' [to] link to 'francoščina':

[[:sl:francosko]] is a redirect to [[:sl:francoščina]]: francosko

so it would appear that what you want already exists. Am I missing something?

—Trappist the monk (talk) 11:20, 26 May 2023 (UTC)[reply]

I would like the links to point directly to the language name and bypass redirects. This is particularly the case because not all redirects have been created yet. If I add this module to a template (e.g. a highly visible one), not all links will be functional as many redirects don't exist yet. In addition, it is preferable to have articles mostly linked directly and not via redirects, because it improves user experience (seamless navigation and less risk of confusion). Another issue is that the 'lang' templates have been implemented with piped links, so this would also help with consistency. --TadejM ^{my talk} 05:54, 27 May 2023 (UTC)[reply]

The notion that redirects are bad is nonsense. MediaWiki would not support redirects if they were bad; there must be more than a million redirects here at en.wiki.

I looked at sl:Template:lang-fr which has:

|label={{ifeq|{{{label|}}}||[[francoščina|francosko]]}}

I'm not sure why you do that because you have sl:Module:Language/data/iana languages translation. For example, at sl.wiki:

{{lang|fn=name_from_tag|fr|link=yes}} → [[francosko|francosko]] (not sure why you do that)

and we've already established that [[francosko]] cleanly and easily redirects to francoščina so the |label= manipulation in sl:Template:lang-fr seems extraneous.

Redirects don't exist? Anyone can make a redirect; template and module coding skills are not required so that rationale for changes to Module:Native name doesn't impress me. Besides, Module:Native name only knows what Module:Lang gives it. If Module:lang is correct, Module:native name is correct.

—Trappist the monk (talk) 13:30, 27 May 2023 (UTC)[reply]

This is how these templates were implemented initially, so this preserves the initial format. I am a) not entirely convinced that redirect are superior to piped links and b) don't think I have community consensus to replace piped links with redirects. I agree that piped links containing the same target and displayed name are redundant, but I have not yet researched how to resolve this. In any case, this has not posed any practical issues so far. In my opinion, these templates should all function in the same manner, so having some of them as redirects is not preferable. --TadejM ^{my talk} 16:20, 27 May 2023 (UTC)[reply]

English varieties appear, but Spanish and French varieties don't?

I was using this template when I came across an error, Spanish and French varieties don't appear, but English varieties do appear.

Here's an example of what I mean:

Input	Output
`{{Native name\|en-US\|Bob}}`	Bob (American English)
`{{Native name\|en-CA\|Bob}}`	Bob (Canadian English)
`{{Native name\|es-MX\|Bob}}`	Bob (Spanish)
`{{Native name\|fr-CA\|Bob}}`	Bob (Quebec French)

Can someone please make it so that the Spanish and French varieties appear just like the English varieties do? – Treetoes023 (talk) 02:53, 22 July 2023 (UTC)[reply]