mic_none

Module talk:ISO 639 name/ISO 639 name to code Source: en.wikipedia.org/wiki/Module_talk:ISO_639_name/ISO_639_name_to_code

Two suggestions

[edit]

Hi, is it possible to add two features?

Thanks.-- Carnby (talk) 20:12, 3 September 2024 (UTC)[reply]

ISO 639 does not recognize Mozambican Portuguese. Not in ISO 639? not going to be added to a template specifically for ISO 639 recognized languages.
If you want to create a shortcut (did you mean a redirect?) to {{ISO 639 name link}}, go ahead.
—Trappist the monk (talk) 20:41, 3 September 2024 (UTC)[reply]
I've just discovered {{Llink}}, seems to be fine. Thanks anyway.-- Carnby (talk) 05:15, 4 September 2024 (UTC)[reply]

Mono language issue

[edit]

There is an issue with this language, see the following:

Gonnym (talk) 13:45, 27 October 2024 (UTC)[reply]

You must tell the template which of the four you want. The name must be exactly as it is listed in the ISO 639 data modules (for a list of them, see Module:ISO 639 name § Data mapping):
  • {{ISO 639 code|Mono (Democratic Republic of Congo)}} → mnh
  • {{ISO 639 code|Mono (USA)}} → mnr
  • {{ISO 639 code|Mono (Cameroon)}} → mru
  • {{ISO 639 code|Mono (Solomon Islands)}} → mte
—Trappist the monk (talk) 14:17, 27 October 2024 (UTC)[reply]
Ah, thanks for reminding me of this. Do you have any idea why {{IPA|mnr|test}} gets the non-disambiguated name (Category:Pages with Mono IPA)? Gonnym (talk) 14:26, 27 October 2024 (UTC)[reply]
To get the language name, Module:IPA uses:
{{lang|fn=name_from_tag|mnr}} → Mono (lines 65–72)
Module:Lang always strips IANA/ISO disambiguators. Module:IPA might do better to fetch the name from Module:ISO 639 name using the |raw=yes parameter:
{{#invoke:ISO 639 name|iso_639_code_to_name|mnr|raw=yes}} → Mono (USA)
also available to the template:
{{ISO 639 name|mnr|raw=yes}} → Mono (USA)
—Trappist the monk (talk) 15:00, 27 October 2024 (UTC)[reply]
Is _iso_639_code_to_name (frame) meant as a module entry point also? It currently doesn't work like _iso_639_name_to_code (args). Gonnym (talk) 15:29, 27 October 2024 (UTC)[reply]
Not clear to me why the code is written as it is. Usually, when I use an underscore-prefixed function name, that name (if exported) is for access from another module. _iso_639_code_to_name (frame) is not exported and because it accepts frame as a variable, would be a template access point. Mayhaps I got started on creating module access points and got side-tracked? Don't know, I'll give some thought to fixing that.
—Trappist the monk (talk) 16:43, 27 October 2024 (UTC)[reply]
@Trappist the monk: That doesn't work because the input can be an IETF tag. Barring an exposed function to fetch the language name, the article to link, the raw name, and the canonical/sanitized tag from an IETF tag all at once (which would be great), is there no equivalent to {{#invoke:Lang|category_from_tag}} except it returns just the language part, i.e. without "Articles containing" or "-language text"? Nardog (talk) 05:27, 26 December 2024 (UTC)[reply]
What do you mean by: the input can be an IETF tag? {{ISO 639 name}} supports ISO 639-1, -2, -3, and -5 language tags only. It does not support IETF language tags. The only category link emitted by {{ISO 639 name}} is Category:ISO 639 name template errors; there is no other categorization.
—Trappist the monk (talk) 15:20, 26 December 2024 (UTC)[reply]
You said Module:IPA might do better to fetch the name from Module:ISO 639 name using the |raw=yes parameter. I'm pointing out that doesn't work because e.g. {{IPA|pt-BR|...}} needs to show the same label as {{langx|pt-BR|...}} (which, if used in an article, puts it in Category:Articles containing Brazilian Portuguese-language text rather than Category:Articles containing Portuguese-language text). Nardog (talk) 15:28, 26 December 2024 (UTC)[reply]
That was for the rare case of Mono, a name shared by several different languages, each with its own language tag. If {{IPA}} and {{Langx}} must show the same label then {{ISO 639 name}} is not the correct tool for {{IPA}}.
How {{langx}} categorizes out-of-scope for {{ISO 639 name}}.
This is the wrong venue to be discussing changes to Module:Lang. Certainly Module:Lang can be tweaked so that name_from_tag() supports |raw=yes. It would be up to Module:IPA to decide what it does with that parameter.
—Trappist the monk (talk) 16:42, 26 December 2024 (UTC)[reply]
You're telling me. I'm pointing out you and Gonnym were missing a bigger picture when suggesting Module:IPA use this module.
So is there no exposed function that converts e.g. pt-BR to "Brazilian Portuguese" and mnr to "Mono (USA)", i.e. what {{lang(x)}} does to generate categories? Can you make one? Nardog (talk) 16:52, 26 December 2024 (UTC)[reply]
There is no support in Module:ISO 639 name for IETF language tags because IETF is not ISO 639. Module:ISO 639 name will return a language name from an ISO 639 language tag:
{{ISO 639 name|pt-BR}} → Portuguese error: pt-BR is an IETF tag (help)
{{ISO 639 name|mnr}} → Mono
and to get the name with disambiguator (if present):
{{ISO 639 name|mnr|raw=yes}} → Mono (USA)
—Trappist the monk (talk) 17:16, 26 December 2024 (UTC)[reply]
Again, I'm only asking here because you were already having a relevant discussion here. I'm not asking if this module has it, I'm asking if any module does. Nardog (talk) 17:19, 26 December 2024 (UTC)[reply]
Then Module:Lang should also have a |raw=yes option to get the full name. Gonnym (talk) 17:44, 26 December 2024 (UTC)[reply]
Which I suggested could be done but that was apparently ignored. I've added it:
  • {{lang|fn=name_from_tag|mnr}} → Mono
  • {{lang|fn=name_from_tag|mnr|raw=yes}} → Mono (USA)
—Trappist the monk (talk) 18:10, 26 December 2024 (UTC)[reply]
If that was meant to me, I wasn't ignoring you, I was agreeing with you. Gonnym (talk) 18:27, 26 December 2024 (UTC)[reply]
Twas meant for you; just noting that Editor Nardog had apparently ignored that part of my post.
—Trappist the monk (talk) 18:59, 26 December 2024 (UTC)[reply]
I wasn't ignoring it, I just didn't realize that was precisely what I was asking! Nardog (talk) 19:00, 26 December 2024 (UTC)[reply]
[edit]

Template:ISO 639 name link transcludes the documentation for Template:ISO 639 name, however, it functions differently in that it automatically adds a link. Is there an easy way to resolve this? I mean, can we tailor the documentation to the link template without having to copy-paste the documentation entirely? — W.andrea (talk) 23:39, 29 March 2025 (UTC)[reply]

You might consider doing something like {{sfn}} does. That template shares its documentation with several Harvard-style short-form reference templates. The common documentation template is {{Harvard citation documentation}}.
So for {{ISO 639 name}} and {{ISO 639 name link}}, perhaps {{ISO 639 name documentation}}. That template would be called from Template:ISO 639 name link/doc with {{ISO 639 name documentation|link}}. In {{ISO 639 name documentation}} you might have under usage:
* {{tnull | ISO 639 name {{{1|}}} | ''ISO code''}}
which would render:
  • {{ISO 639 name|ISO code}} – for the unlinked form
  • {{ISO 639 name link|ISO code}} – for the linked form
Similarly, this would not want to be part of the {{ISO 639 name link}} documentation:
* {{tnull | ISO 639 name | fn{{=}}iso_639 | ''ISO code or language name'' | link{{=}}yes| hide-err{{=}}yes }}
You might want to write something like:
*{{#if:{{{1|}}}||{{tnull | ISO 639 name | fn{{=}}iso_639 | ''ISO code or language name'' | link{{=}}yes| hide-err{{=}}yes }}}}
(might want to put that at the end of the §Usage section in order to mind the list gap)
In a like fashion, {{ISO 639 name documentation}} would be called from Template:ISO 639 name/doc with {{ISO 639 name documentation}} (no positional parameter set).
—Trappist the monk (talk) 00:11, 30 March 2025 (UTC)[reply]