This template is within the scope of WikiProject Korea, a collaborative effort to build and improve articles related to Korea. All interested editors are invited to join the project and contribute to the discussion. For instructions on how use this banner, please refer to the documentation.KoreaWikipedia:WikiProject KoreaTemplate:WikiProject KoreaKorea-related
This template is within the scope of WikiProject Linguistics, a collaborative effort to improve the coverage of linguistics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinguisticsWikipedia:WikiProject LinguisticsTemplate:WikiProject LinguisticsLinguistics
Support. Thank you so much for all of the work you and your IP friend have put into this. The new templates will solve widespread problems and hopefully prevent more from cropping up in future. This is especially important when we know many prominent academics copy basic information like dates and romanizations straight from Wikipedia. Toadspike[Talk]20:38, 21 April 2025 (UTC)[reply]
Question on the proposed method: Could you provide detailed statistics from the impact analysis for the scenario(s) mentioned in this subsection? For cases outside of these scenarios, what are the possibilities of using actual bots (i.e., not AWB operated manually by a human clicking "Save") to avoid disruptive situations like this and this as much as possible. Please also note that, as stated in meta:Tech/News/2024/08, "edits by bot accounts no longer trigger notification emails". Additionally, what would be the impact of integrating the auto-coding logic directly into the current template rather than performing a large-scale replacement? And if replacement is preferred, why should the auto-titled version (e.g., {{Infobox Korean name/auto}}) become the stable version over the existing non-auto version ({{Infobox Korean name}}) after the entire replacement procedure is completed? This seems inconsistent with the general titling policy, where the base name typically refers to the stable or standard version. โPaper9oll(๐ โข ๐)14:49, 22 April 2025 (UTC)[reply]
I am not seefooddiet but the numbers listed under "Task" likely come from the transclusion count tools: [1][2] These total 37589 transclusions, though as seefooddiet said there is likely a lot of overlap between the two templates. I'm also not sure if that tool counts several transclusion on one page separately. Both would lower the number of edits required to implement this.
Regardless, the maximum of 38K edits is far lower than the millions done by Cewbot, which means that the edit rate can be lower and there is less overall disruption. Doing it by AWB, unless seefooddiet is an absolute legend, means the ~20 edit-per-minute maximum which gained rough consensus in those discussions is highly unlikely to be surpassed. Is this the kind of explanation you were looking for? Toadspike[Talk]15:02, 23 April 2025 (UTC)[reply]
Thank you for clarifying that {{Infobox Korean name/auto}} should redirect to {{Infobox Korean name}}, and similarly, {{Korean/auto}} should redirect to {{Korean}}. I also acknowledge the point that "the maximum of 38K edits is far lower than the millions done by Cewbot, which means the edit rate can be lower, resulting in less overall disruption," and that "~20 edits per minute as a maximum is highly unlikely to be surpassed".
However, the third question is still pending. Additionally, I would like to raise another question: I am not entirely sure if this proposed implementation was previously discussed with the community and reached consensus, as I couldn't find relevant materials to review; could we consider replacing the use of symbols in |hangul= to more user-friendly options, such as parameters with short, descriptive, and easy-to-remember values? For instance, if the value in |hangul= represents a personal name, we could introduce a |type= parameter where editors could simply enter "name" as the value rather than relying on symbols like % that carry no inherent meaning. This approach is inspired by {{Infobox album}}, {{Infobox song}}, and other infoboxes that use similar if-else logic, and it should function in a comparable manner.
Recognizing the effort that has gone into the existing proposed coding, was thinking if we could consider adding new wrapper functions that convert parameters into the symbol format? This would maintain backward compatibility with the existing symbol-based approach in the backend, while allowing the frontend to adopt the more user-friendly parameter-based approach. โPaper9oll(๐ โข ๐)16:47, 23 April 2025 (UTC)[reply]
Note that I'm currently working out scenarios where bots could speed up this process, which is why I haven't replied to bot point yet seefooddiet (talk) 22:14, 23 April 2025 (UTC)[reply]
On the symbols, there are a number of reasons for them. A personal name can appear as part of a longer string (e.g. ๋ฐ์ ํฌ ๋ํต๋ น ์๊ฐ (Birthplace of Park Chung Hee)). The entire string shouldn't be processed as a name; you'd need to mark where a person's name begins and ends in such strings. seefooddiet (talk) 23:22, 27 April 2025 (UTC)[reply]
For such "edge" (not sure the stats, just bombing the word) cases, I believe my proposed approach still works. Take your illustration as example, if |type=special, add |special=๋ฐ์ ํฌ, backend logic checks if |hangul=๋ฐ์ ํฌ ๋ํต๋ น ์๊ฐ contains the exact match of the text in |special=, and add % escaping to only that specific text. However, if |type= isn't value of "special" then |special= would be ignored completely. โPaper9oll(๐ โข ๐)02:41, 28 April 2025 (UTC)[reply]
What if there are multiple names in different places in a string? For example, "๋ฐ์ ํฌ๊ณผ ํ๊ธธ๋์ ๋ง๋จ", where ๋ฐ์ ํฌ and ํ๊ธธ๋ are both names. seefooddiet (talk) 02:48, 28 April 2025 (UTC)[reply]
Was thinking of |special=๋ฐ์ ํฌ,ํ๊ธธ๋ or simply |special=๋ฐ์ ํฌ|special2=ํ๊ธธ๋. Ideally, the |type= and its accompanied param of the same name could be adjusted accordingly depending on the use cases. My approach is to minimize the complexity from the frontend as much as possible, leaving all those complexity to the backend to handle as it would in every projects. โPaper9oll(๐ โข ๐)02:52, 28 April 2025 (UTC)[reply]
I appreciate the input. I have other problems with that formulation (there are enough possible modifications that a single "special" parameter wouldn't work). I'll do some brainstorming on how to improve user-friendliness.
Thanks for the understanding. Nothing for now. Do let me know if you needed help in brainstorming. I currently don't have prior work experience on Lua itself, I'm trying to learn it to see if I could help out if required. โPaper9oll(๐ โข ๐)11:53, 28 April 2025 (UTC)[reply]
@Paper9oll Proposing a middle-ground solution. It's not perfect but it should cover most common usecases of these templates.
How would you feel about these checkbox parameters being added?
|namemode=. This parameter would only be appropriate if the string is just a person's name, e.g. "ํ๊ธธ๋". Another requirement is that the surname only be one character long. Behind the scenes, this parameter just adds % before the name, like %ํ๊ธธ๋; the only real difference is that the user wouldn't need to add that symbol themselves. The param would be inappropriate if the string was "๋ฐ์ ํฌ ๋ํต๋ น ์๊ฐ"; for that string, users shouldn't use this parameter and instead need to manually input "%๋ฐ์ ํฌ% ๋ํต๋ น ์๊ฐ".
|capitalize=. Similar, except adds a ^ before Hangul string (capitalizes first letter of romanization).
Again, these two parameters would cover a significant proportion of uses of both {{Korean/auto}} and {{Infobox Korean name}}. I know it's still not perfectly user friendly, as the symbols still exist, but it's closer I think. grapesurgeon (formerly seefooddiet) (talk) 19:54, 11 May 2025 (UTC)[reply]
@Grapesurgeon Yup, that looks good for now for the 1st production revision. It could be improved in the future for the remaining cases. For personal names, which I believe are a high-usage case (especially those with single-syllable surnames), this would be more user-friendly. โPaper9oll(๐ โข ๐)08:02, 12 May 2025 (UTC)[reply]
By the way, I am not really in favor of adding parameters.
If you don't like % for a personal name, I guess it is possible to introduce this BBCode-like syntax instead: [name]ํ๊ธธ๋[/name], but [/name] at the end of a string is omitted. Examples:
Entire string consisting of a single personal name: [name]ํ๊ธธ๋
For capitalization, I think ^ is good enough. ^ is one of the characters on the QWERTY and Dubeolsik keyboards which is quite useless in most contexts. And since ^ is graphically pointing upwards, I think this is easy to remember.
Well, verbosity is one of the reasons that I used a single character % for a personal name. But now, there is at least one person who does not seem to like this, so I made the suggestion above. Also, checkbox parameters are even more verbose.
Just to be clear, I don't want to make the syntax more verbose either. I prefer keeping the current syntax that uses a single character for each purpose, without parameters. 172.56.232.226 (talk) 00:46, 14 May 2025 (UTC)[reply]
When considering the design for this new template, especially for broad community use, it's important to find a balance between different needs.
While I recognize that a very limited and abstracted use of symbols on the backend, perhaps surfaced through simple, specific parameters for high-frequency, straightforward cases (like the previously discussed 'checkbox' parameters for an initial version), might offer some conciseness, the overall design philosophy for the template's frontend should strongly align with established Wikipedia best practices. The established standard for template design on English Wikipedia heavily favors the use of named parameters (e.g., |parameter_name=value). This approach offers significant advantages in terms of discoverability, ease of use for editors with diverse experience levels, and consistency with the vast majority of other templates. Adhering to this standard helps ensure the template is more self-documenting and accessible to the widest possible range of contributors.
A design that leans heavily on custom single-character symbols for its primary user interface, or even BBCode-like tags, would represent a departure from these widely adopted community norms. Such non-standard syntaxes can create a steeper learning curve and may appear opaque to those not intimately familiar with this specific template's design. The suggestion of a BBCode-like syntax, while an alternative to raw symbols, presents its own challenges as it's a highly unconventional approach for MediaWiki template design and could raise questions about maintainability and compatibility with editing tools.
Therefore, in the context of this RfC for the new template, my recommendation is for a design that prioritizes a clear, parameter-based interface for user interaction. While the backend module might internally utilize symbols for efficiency, the frontend experience should be guided by the principles of accessibility and consistency that parameters provide. This allows for a user-friendly system that can still accommodate simple use-cases efficiently, perhaps through very specific parameters in an initial rollout, while ensuring the broader, more complex interactions are handled in a standard, parameter-driven way.
Given that this RfC involves a core technical design choice between a symbol-based (non-standard) versus a parameter-based (standard practice) interface for this proposed template, and we haven't yet seen significant discussion on these technical preferences, would it be beneficial to seek broader input from the community at Wikipedia:Village pump (technical)? This might help us gather more perspectives from editors experienced in template design and MediaWiki conventions to ensure we're aligning with best practices for usability and maintainability. โPaper9oll(๐ โข ๐)09:15, 14 May 2025 (UTC)[reply]
I agree with BBCode being uncommon; I've never seen it used in other modules. Would definitely be a drawback of that approach.
For village pump req, it's a good suggestion but I'll respectfully decline for now. I think it wouldn't offer much more insight and add more time to the project, and would rather move forward. I've already posted on Template talk:Lang about this RfC. grapesurgeon (seefooddiet) (talk) 17:04, 14 May 2025 (UTC)[reply]
