Category talk:Redirects from ISO 639

WP:BOTREQ
http://en.wikipedia.org/w/index.php?title=Wikipedia%3ABot_requests&diff=125030681&oldid=125010958 Tobias Conradi (Talk) 22:15, 23 April 2007 (UTC)

current: Bot_requests

Which redirect formats?
Currently, redirects exist (or at least are supposed to exist) for all ISO 639-1, 639-2 and 639-3 codes, and they're of the form ISO 639:aa (for ISO 639-1 codes) and ISO 639:aar (for 639-2 and 639-3). So far, so good. But there are sporadic redirects with an alternative format, such as ISO 639-3:nan, and I notice that has recently created about 60 similar redirects for ISO 639-1 codes (e.g. ISO 639-1:gn).

Should we strive to support redirects of that format as well? I don't think they're needed: they're something of a technical necessity that isn't rooted in some frequent pattern of readers searches, so we don't need to accommodate variants of that: one format is enough. On the other hand, even though the extra redirects are individually harmless, I don't fancy the prospect of suddenly having double the number of ISO redirects to look after. – Uanfala (talk) 17:22, 21 June 2022 (UTC)


 * @Uanfala I did look into whether it's possible to get these to track with the pre-existing redirects, because it would be useful for these to be "set and forget" so that they don't cause issues in the event that any redirects need to be changed to something else.
 * I also note that these are currently inconsistent with the formatting used for ISO 3166, which does specify the part: for example, ISO 3166-1:GB. I also find that these are useful when searching for anything ISO related, and I can't be the only one, even if most users won't use them. Theknightwho (talk) 17:29, 21 June 2022 (UTC)
 * , thank you for not creating any more redirects of this type. We disagree on their benefits, but I think we agree that if they are to be created, that would need to happen for all ISO language codes (we shouldn't provide for search strategies that will only work in a handful of cases, right?). Still, you don't have to specifically get my consent for a project like that. If you're still interested in it, the way forward is to start a community discussion (WT:LANG would be a good place), and if there eventually is consensus for that, you can then post the task at WP:Bot requests. Getting a bot to create the redirects should be easy, though keeping them in sync probably less so. In principle, there is a redirect category that can help in cases like that: R from avoided double redirect, but I'm not aware of any existing bot machinery that takes advantage of it. – Uanfala (talk) 13:06, 26 June 2022 (UTC)
 * @Uanfala Fair enough! It does seem as though the various ISO 639 coding systems don't clash with each other, which is helpful. I did have a look at whether double redirects are possible, and it turns out people have been requesting them for almost as long as Wikipedia has been around for precisely this reason: sometimes you want a 'main' redirect which can be changed (e.g. article merge, splitting out a section etc.), but there may be other redirects which you know will never be independent from that main one (e.g. variant spellings). There didn't seem to be huge resistance to it, but it's one of those technical things that has just never gathered the momentum to get implemented, because obviously it would need to be done carefully to prevent abuse.
 * In any event, I'll raise the discussion at some point. In an ideal world we'd have both, but I appreciate that it would be worse if they accidentally became detached from each other. Theknightwho (talk) 13:28, 30 June 2022 (UTC)
 * In any event, I'll raise the discussion at some point. In an ideal world we'd have both, but I appreciate that it would be worse if they accidentally became detached from each other. Theknightwho (talk) 13:28, 30 June 2022 (UTC)
 * In any event, I'll raise the discussion at some point. In an ideal world we'd have both, but I appreciate that it would be worse if they accidentally became detached from each other. Theknightwho (talk) 13:28, 30 June 2022 (UTC)