the new version of langprefix

Fragment of a discussion from User talk:CodeCat
Jump to: navigation, search

See google:"explicit is better than implicit" and "similar things should look similar; different things * different". I hold that distinctions such as these:

  • a language that we want in mainspace vs. a language that we allow only in appendices
  • a link to a mainspace entry vs. a link to an entry-like appendix

are fundamental distinctions that should always be visibly evident — and, in fact, that are visibly evident, when you navigate the site as a reader. We require our readers to understand these distinctions (if they want to find what they're looking for), and we require our editors to understand them (if they want to create the right pages in the right locations); therefore, a template that papers over these distinctions in the edit-window is doing a disservice by making things look more similar than they are, and by having radically different behavior depend on superficially near-identical wikitext.

RuakhTALK19:00, 24 October 2012

drama woo!

Now to the actual thing:

where is the problem in just writing ex. {{etyl|proto:gem-pro|de}} or similar? I fail to see it. Or am I missing something here?

Liliana 20:17, 25 October 2012

There is absolutely no problem with {{etyl|proto:gem-pro|de}}, either in theory or in practice. In fact, that already works; it's just that {{etyl|gem-pro|de}} also works.

But {{etyl}} is a special case, since (1) its argument isn't necessarily a language code, or even a fake language code — we can write {{etyl|Vulgar Latin|fr}}, for example — and (2) we can simultaneously have {{etyl:el}} and {{el}}, for example, if we want {{etyl|el}} to display "Modern Greek" while {{onym|el|foo}} links to [[foo#Greek]]. The etyl: templates really belong to {{etyl}}; probably we should have made them explicit subtemplates, by using names like {{etyl/Vulgar Latin}} instead of names like {{etyl:Vulgar Latin}}. The only connection between etyl: and proto:/cons:/etc. is that the former was apparently the inspiration for the latter.

A more typical case is {{term}}. Currently, something like {{term|...|lang=proto:gem-pro}} does not work. The problems are: (1) it doesn't know to link to an appendix (which can be fixed, by having it check for initial proto:); (2) it will actually put lang="proto:gem-pro" in the HTML (which would be easy to fix if we had Scribunto; since we don't, I think we'd have to create a new set of language subtemplates, called e.g. {{fr/HTML lang}} or whatnot, for mapping e.g. fr to fr and proto:gem-pro to x-gem-pro — though if we want, we could avoid creating it for mainspace languages . . . suffice it to say, if we want to go this route, I have some thoughts on the subject); (3) it uses the script-template {{Eror}} (because, for reasons I can no longer recall, {{Xyzy/script}} won't try e.g. {{fr/script}} if it finds that the language-code includes URI-special characters; that's easy to "fix", in theory, by removing that check, but I'm loath to do so without remembering why it was included to begin with); and (4) possibly other problems I haven't thought of. These problems are surmountable if we want to do it this way; personally, I think I'd prefer something like {{term|...|langprefix=proto|lang=gem-pro}}, but there are multiple valid approaches.

RuakhTALK21:10, 25 October 2012