Wikifunctions talk:Best practices

New best practice for new best practices

I boldly suggested that the main page should not be added to or amended without first proposing the change here. I am now proposing that this be adopted as a best practice! GrounderUK (talk) 19:36, 10 March 2024 (UTC)

Isn't 'proposal for a best-practice' essentially an essay? Besides, I think it would be odd for a wiki to have a rule saying not to edit a page even to improve it. Arlo Barnes (talk) 00:27, 12 March 2024 (UTC)

I suppose it may be an essay, but I wouldn’t expect it to be. Wikifunctions:Naming conventions is an essay. Are the ideas there put into practice? Should they be? I don’t know, so let’s discuss it (below).

I don’t think it makes sense to talk about Best practices unless there is a community consensus behind them. And if consensus has been achieved, it is appropriate (in my view) to discuss any changes before changing what has been agreed. That is why I propose that it should be considered a Best practice to discuss changes first. But it is just a proposal! GrounderUK (talk) 11:48, 12 March 2024 (UTC)

Wikifunctions:Naming conventions

Are these adopted as they stand? GrounderUK (talk) 00:29, 12 March 2024 (UTC)

@GrounderUK: Maybe? I'd suggest a ping on WF:Project chat that this page exists and proposals are being discussed before we make things "official" though? Jdforrester (WMF) (talk) 14:56, 12 March 2024 (UTC)

Yes, it’s on my to-do list. Thanks! GrounderUK (talk) 15:02, 12 March 2024 (UTC) Done

I’ve added a paragraph on characters that might cause difficulties in searches. (phab:T361015.)

There was a clear poll on the capitalisation section here: Wikifunctions:Project_chat/Archive/2023/08 (at the end of that page) --99of9 (talk) 04:37, 8 April 2024 (UTC)

Connecting tests

"If a test is a valid statement about how the function should evaluate, then it should be connected to the function even if no implementation currently passes the test." from Wikifunctions:Project_chat/Archive/2023/12#Questions_around_string_reversal_and_tests --99of9 (talk) 11:00, 12 March 2024 (UTC)

Connecting implementations

"Implementations which have inferior accuracy compared to other connected implementations across the currently connected tests should be disconnected. For this purpose, timeouts are not necessarily counted as inaccurate." from [1]. --99of9 (talk) 11:06, 12 March 2024 (UTC)

Generalize functions with code as much as possible

Don't: add a new function "swedish noun -s declension" that do exactly the same as "german -s declension" ie add -s to end of a string with a python code implementation in each.

Do: create a new function like add suffix to string if it does not already end with the suffix (Z17973) that takes a string and a suffix and use it in compositions in all the language functions that need it when possible. (Idea by @GrounderUK) So9q (talk) 10:52, 19 July 2024 (UTC)

Hmm. I was always vaguely assuming that those functions would switch from taking a generic string (Z6) to taking a monolingual string (Z11) in whatever language. There'd then be the possibility for a "front-of-house" function to take a Z11 in many languages and match it to the appropriate function on the back-end. Having general low-level functions instead is of course also a possibility. What do people think we should do? Jdforrester (WMF) (talk) 15:49, 19 July 2024 (UTC)

I would think the outer function is language-specific (and this is where we might interact with Wikidata Lexemes, particularly for irregular forms). The innermost functions can be pure string manipulations for regular forms/representations. A “front-of-house” dispatch function would need to know something about the language the input text is in and something about its grammatical features. But whether the result is derived or fetched from a Lexeme should not affect the function’s return type, so I would expect that for outer functions it would generally be Multilingual text (Z12) or Monolingual text (Z11) (where the required form is specific enough). Another structure to consider, though, is a single string with an array of “languages”, for cases where a representation is common to many language variants. Similarly, when different forms or lexemes have the same representations, a single representation (or set of representations) and an array of lexeme form types. GrounderUK (talk) 19:46, 19 July 2024 (UTC)