the new version of langprefix

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

You have repeated this many times but you have never considered the consequences of having to either duplicate or modify every template that takes a language code.

CodeCat18:13, 24 October 2012

Firstly: Not that many templates take a language code, and of those that do, most don't need this. ("Form-of" templates, translations-templates, etc., don't need to support appendix-only languages.)

Secondly: You and others have already duplicated or modified (or both!) all of these templates, repeatedly, as part of your campaign to paper over the distinction between first-class-citizen languages and appendix-only languages. It's not that I haven't "considered the consequences" of fixing that mess; it's that I consider those consequences to be positive consequences, manifestly superior to the status quo.

RuakhTALK18:21, 24 October 2012

Form-of templates do need it. See *þat. Again you have repeated this many times, but I still don't understand how you expect your system to work in practice, nor do I understand how you think your system is more editor-friendly than what we have now. And if it is not intended to be editor-friendly, what is the point? Why would we agree to have something that makes it harder for us to do things?

CodeCat18:26, 24 October 2012

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