the new version of langprefix
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?
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.