Smalyshev added a comment. > The sitelinks are distinguishable by the URL (https://simple.wikipedia.org/)
URL is the different triple than the data, and matching URLs means that the client should maintain own database which says which Wiki URL matches which language and do pattern matching on the URL data. This does not sound to me like a good solution, both performance-wise and design-wise. This also couples two things (language and URL) which should not be coupled as they describe two different things. Since we have triple using schema:inLanguage and data using language tags, we should ensure those have right values, instead of relying on other information to fix wrong values there. > en is also a standard language code. True, but it does not adequately describes the data which refers to "Simple English", not just "English". Just as "nl" would not adequately describe data that refers to "nl-informal", etc. That would be loss of information, and we should avoid that when exporting data. > When you change the language codes at the right position the RDF export gets > automatically the correct language codes. So far I have seen no code that does such change and I do not feel comfortable starting a project for refactoring whole language handling in whole MediaWiki (which would be required if we just change `Site::getLanguageCode()`), when I just need a right language tag in RDF. If that refactoring ever happens and solves that particular problem, I would be glad to refactor this particular fix. But remaining without fix until an undefined moment that this happens does not sound like a good way to go for me. > I think it is bad programming style to make several workarounds instead of > fixing the core problem. If somebody volonteers to fix the core problem, I think that would be excellent. If not, as it has been evidently happening since 2012, I don't see what use it is to discuss a hypothetical fix that might have been instead of fixing the actual thing that needs to be fixed. Following this strategy would lead us only to discussing solving bigger and bigger global solutions in theory without actually getting a thing done in practice. TASK DETAIL https://phabricator.wikimedia.org/T105430 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Fomafix, gerritbot, Smalyshev, Aklapper, daniel, mkroetzsch, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, JanZerebecki, Malyacko, P.Copp _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
