Module talk:City

Default language

@Jarekt: thanks for all your work on this module ! There is however an issue with the language used when no lang parameter is provided, as can be seen in Module talk:City/testcases. It seems to be cause by mw.message.new( "lang" ):plain() that salways return "en" whatever the user's language. The only solution I can find is mw.getCurrentFrame():preprocess("en"). --Zolo (talk) 10:31, 15 September 2016 (UTC)

Zolo, My default language is "en" and Module talk:City/testcases has no errors; however you are right that Module talk:City/testcases?uselang=pl has errors and mw.message.new( "lang" ):plain() is not working right which I think is due to phabricator:T142906 issue. Anyway Module talk:City/testcases is outdated as it comparing Module:City to template:City, but template template:City now relies on Module:City. I will change it so the comparison is between template:City and template:City/old which holds pre-LUA version of the template. The issues you are seeing are OK when you access the module through template:City, which calls en so mw.message.new( "lang" ):plain() part of the code is never used. --Jarekt (talk) 13:56, 15 September 2016 (UTC)

@Jarekt: I don't think it is related to phabricator:T142906:

T142906 explains why some content remains in the user's default language when ?uselang is added to the URL. Here, it is something different:, even when you change your default language to another language, {{#invoke:City|city|place=London}} shows English links and labels (London) which does not sound right. That occurs because mw.message.new( "lang" ):plain() does not return the user's chosen language, but the site default laguage, viz en. On the other hand {{city|London}} does use the user's chosen language because the default is overridden to {{int:lang}} by Template:City. --Zolo (talk) 16:25, 15 September 2016 (UTC)

Zolo, You are right something is broken. I just run some tests and after changing my preferred language to Polish botch mw.message.new( "lang" ):plain() and mw.message.getDefaultLanguage():getCode() return "en". See below results of {{#invoke:Test|lang}}: --Jarekt (talk) 17:04, 15 September 2016 (UTC)

Jarekt, I've read somewhere that there is a difference between the default language of the site and the language of the user. getDefaultLanguage() returns the site's default language, which is English on Commons and Polish on plwiki, even when the user's change's his own language settings. To get the user's language, it is apparently necessary to use {{int:lang}}.

By the way, you can easily test another language adding ?setlang=xx to the URL (as opposed to ?uselang=xx). --Zolo (talk) 07:46, 16 September 2016 (UTC)

I also agree that Jarekt is confused about the difrence between default language and user language. He made similar errors elsewhere while trying to solve another problem where he mixed the two. The difference is very notably in multilingual wikis like Commons, or MW-wiki, or Meta, or "old" wikisource, or Wikidata. verdy_p (talk) 09:08, 11 September 2017 (UTC)

Wikidata for places not in Module:City/data

Couldn't STEP 4 look up the item for a gallery it finds and use it? So it would be possible to use 'link' for them. And this would be very useful for the creator template data migration process. (It wouldn't help with this directly, it would need implementation in the "look up q-codes of locations" section of Module:Creator.) I think there are quite a lot places that fall in STEP 4 and have to be handled manually currently (e.g. deathloc here). Cheers, --Marsupium (talk) 21:20, 25 August 2017 (UTC), 08:40, 26 August 2017 (UTC)

Marsupium, That is a good idea. I wrote a new version of Module:City/sandbox that can recover q-codes from galleries and categories with sitelinks from wikidata. I tested the galleries option but still have to find a case where there is no gallery but there is a category with a sitelink from category item. --Jarekt (talk) 13:17, 28 August 2017 (UTC)

 Done --Jarekt (talk) 21:24, 28 August 2017 (UTC)

Thank you! On Creator:Jan Grubiński it works like a charm. Perhaps Module:City can somehow be called from Module:Creator itself (not just Module:City/data) to give the QID to QuickStatements?? --Marsupium (talk) 21:57, 28 August 2017 (UTC)

yes I was planning to do that so I split _city function into qCode and _city functions. First one returns q-code (if found) and second builds a label based on the q-code or anything else. --Jarekt (talk) 13:28, 30 August 2017 (UTC)

Great! For that functionality it should be possible to filter QIDs inferred through disambiguation pages and categories, e.g. {{city|Dahlem}} -> Dahlem.

What do you think about generalizing the bigger part of the template? I think there are still other use cases and Commons-Wikidata migration will bring up more and more. For example, it would be useful for a more advanced replacement of Template:Kinship/link. --Marsupium (talk) 12:27, 6 September 2017 (UTC)

Pull request

See Module:City/sandbox which swaps out the core to Module:Match link that can easily be reused and is more flexible in choosing of what to link. The performance seems to be the same, from trial to trial sometimes slightly better, sometimes slightly worse. Thanks in advance, --Marsupium (talk) 17:08, 20 September 2017 (UTC) {{edit request|technical=yes}} --Marsupium (talk) 21:09, 13 January 2018 (UTC)

I like the idea of generic Module:Match link, with Module:City being specialized version of it. I still will want to understand the differences between two codes and We would need to change other modules that call 3 Module:City functions to use Module:Match link. I will work on this. --Jarekt (talk) 16:10, 22 February 2018 (UTC)

OK, thank you! I think at some places generic modules can simplify writing of new specialized modules …! --Marsupium (talk) 12:02, 26 February 2018 (UTC)

@Jarekt: Any updates? Sebari – aka Srittau (talk) 15:36, 26 August 2018 (UTC)