[00:13:39] It is not the last editor, I tried purging the page with English as my interface language and it switched to English, then when purging with Hebrew as the interface language it switched back [00:13:54] It is the language of the last purger [00:16:13] Right. [00:16:16] Still not great. [00:18:50] Is it unique to Wikifunctions, or is there anything like that in other wikis? [00:25:35] How does the link text for `[[Z18784]]` render as "ператварыць назву мовы ў рускай мове ў прыслоўе (Z18784)"? That seems to be the goofy bit to me. It kind of looks like things are run through the equivalent of Special:MyLanguage for the UI language of the page editor/purger when the parser runs. [00:26:14] bd808, now it's Belarusian [00:27:41] bd808, I've been testing stuff: I changed my language to Belarusian in the preferences, wrote a Belarusian label for function, and saved the page again. Sure enough, the label changed to Belarusian and the URL changed to include /view/be/, and not only for me, but also for you and everyone else. [00:29:31] And yes, I think that it's wrong in any case, and I reported https://phabricator.wikimedia.org/T372842 [00:30:50] @amire80: https://www.wikifunctions.org/w/index.php?title=User:Amire80/stuff&diff=prev&oldid=125256 -- it is dark magic from how they render a link to a ZObject [00:31:39] the page gets rendered in the UI lang of the editor (purge would act the same) and that gets stuffed into parser cache for the next viewer [00:31:47] Yep. [00:33:23] This may (or may not) be related to the fact that Wikifunctions pages sometimes show other stuff in languages that are unrelated to me: sitenotice banners in Bengali, function aliases in Danish or Thai, etc. [00:34:11] yeah. it looks like UI lang leaks into the parser cache. fun times [00:35:15] (And, like, everyone who knows me for a couple of minutes learns that there are few things I love more than language diversity, but this is just wrong.) [00:43:49] On a different topic. [00:44:27] The message `wikilambda-literal-type` says "Literal $1". [00:48:26] It appears when creating a test, expanding "result validation", and clicking three dots next to "function" (and probably also in some other places). [00:48:58] $1 is a type, which probably means that it can be "function", "string", "boolean", and some other values. "Literal" is an adjective that describes that thing. [00:54:11] It doesn't matter in English, but in Hebrew, Russian, and some languages, the translation of "literal" would be different for different words because of grammatical gender. [00:56:26] I don't think that with the current way in which MediaWiki messages work there is an easy to account for all the types, except creating a different message for each type. And given that, from what I heard, there is an intention to let the community create a lot of different types, that way is not actually feasible either. [00:57:32] So I'm wondering if this workaround would be acceptable: can it be translated as something like "A literal value of type $1"? [01:15:48] (I mean, there are more conceivable solutions. For example, a type definition could have a property that specifies its gender, and then the message could use {{GENDER}}. But I'm not sure that this complexity is justified.) [01:18:57] How does the length compare to other translations that go in that same menu: reference, function call, and argument reference? [01:19:30] As far as I can see, in English they are all one or two words. [01:20:14] But how about in the languages you are trying to translate it to? [01:23:06] In Hebrew and Russian, if I can know the gender, it will be two words. If I cannot know the gender, it will be four in Hebrew. [01:25:10] In Russian... three or four. (It's my mother tongue, but I rarely write technical things in it. I do a lot of software localization into Hebrew, but most of the time other people take care of Russian localization, so I'm less experienced with it.) [01:34:18] More precisely, in Hebrew it would be three words + type name, which may be more than one word. (re @amire80: In Hebrew and Russian, if I can know the gender, it will be two words. If I cannot know the gender, it will be four in Hebrew.) [01:35:54] I don't think that the length is very important, however. Functional correctness is more important—that is, can the user understand what to do without further explanation. And grammatical correctness is of course necessary, too. [01:36:17] I do not know if that will be the best choice, but it will probably be better to have translations that might be able to be shorter than none at all [01:36:44] What do you mean "none at all"? Leaving it in English? [01:37:16] Yes [01:37:22] OUT OF QUESTION. [01:39:15] https://tools-static.wmflabs.org/bridgebot/a169c7f1/file_64234.jpg [01:39:32] I mean, it's not just my obsession with 100% localization. In this particular case, it's also one of the Wikifunctions projects goals, isn't it? To make a library of functions in which everything can be localized. [01:48:29] I was saying to go with the longer translations. If we find a better way to do it (or make a better way as part of Abstract Wikipedia), we can replace them. [02:07:25] So the length, again, is not a problem by itself. Can be short, can be long. I'm just wondering if "A literal value of type $1" is factually and functionally correct. [08:24:47] I think it’s an object, not a value. In some cases, it will look like you are only providing a value, but that’s because an object of that type is defined as type plus value ({"Z1K1": "Zn", "ZnK1": }). I think it says “literal object” when the type is not constrained but I’m not sure that’s the same physical message, because you can end up with both options in [08:24:47] [08:24:48] the same menu. Either way, they are the same in terms of linguistic content. (re @amire80: So the length, again, is not a problem by itself. Can be short, can be long. I'm just wondering if "A literal value of type $1" ...)