Template talk:Korean/auto

RfC: Use of this and another template

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Unanimous approval, albeit open to continual feedback. grapesurgeon (seefooddiet) (talk) 23:11, 8 June 2025 (UTC)

---

Read this page for the full project proposal.

Summary: proposing that this template ({{Korean/auto}}) and {{Infobox Korean name/auto}} gradually replace their predecessor templates {{Korean}} and {{Infobox Korean name}}. These new templates have semi-automatic romanization, as well as a number of other new features. For rationale and specifics, see the linked page above. seefooddiet (talk) 20:14, 21 April 2025 (UTC)

• 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)
• Support, looks great! Should ease reliance on some iffy other tools and improve consistency across all articles. orangesclub 🍊 23:53, 21 April 2025 (UTC)

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)

These are good points, will reply in detail later. For the last point, you're right; I meant to say that {{Infobox Korean name/auto}} should redirect to {{Infobox Korean name}}. seefooddiet (talk) 14:51, 22 April 2025 (UTC)

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)

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)

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)

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)

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)

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)

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)

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.

Assuming this is fixed to your satisfaction, do you have any other concerns? seefooddiet (talk) 02:57, 28 April 2025 (UTC)

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)

@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)

Implemented:

{{korean/auto/sandbox|홍길동|rr=yes|namemode=yes}} → Korean: 홍길동; RR: Hong Gildong grapesurgeon (formerly seefooddiet) (talk) 20:32, 11 May 2025 (UTC)

@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)

By the way, I am not really in favor of adding parameters.

1. 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]홍길동
   • Personal name(s) appearing in a longer string:
     • 국립 [name]홍길동[/name] 기념관
     • [name]박정희[/name]와 [name]홍길동[/name]의 만남
     • 이상한 변호사 [name]우영우
2. 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.

172.56.232.226 (talk) 00:13, 14 May 2025 (UTC)

For public record, I could be convinced of the use of such tags. I don't think such tags would be mutually exclusive with checkbox parameters.

However, I am a little skeptical of how verbose (lot of characters) the tags are. grapesurgeon (seefooddiet) (talk) 00:18, 14 May 2025 (UTC)

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)

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)

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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When to use the "personal name" mode for stage names

Before widely using the semi-automatic templates, there is at least one issue that needs to be discussed: when to use the "personal name" mode for stage names.

1. Some stage names have the "surname + given name" structure – no issue with this; can be treated like ordinary full names (e.g. %홍길동)
2. But some stage names are not in the "surname + given name" structure.
   1. This could be a mononym (= name that does not contain a part which can be perceived as a surname) – no issue with this; can use %_길동
   2. This could be "given name + surname" – probably should use %_길동% %홍
   3. This may not even have the typical form of a personal name – examples: 용감한 형제 (Brave Brothers), 살찐 고양이 (Fat Cat (singer)), etc. How should these be handled?

172.56.232.154 (talk) 14:24, 26 May 2025 (UTC)

I don't see any differences in the before-and-after results for mononyms when using |namemodestage= so far. There are some cases where the results aren't as expected, so I've skipped those for now, while some cases (I believe it's literal translation) where the results is simply error, so skipping those also. Also, could you explain why, for example, %_길동 instead of %길동? Based on my reading of the documentation—even though it’s quite vague—I thought it should be ^%길동 if the syntax is interpreted correctly, even though %길동 worked visually as expected. Was there actually a space to begin with otherwise it's a bug? For now, I'm not updating complex cases—i.e., those that aren't an actual personal name in the traditional sense. — Paper9oll (🔔 • 📝) 14:39, 26 May 2025 (UTC)

1. In the personal name mode, _ is used when the length of the surname is not one syllable. This is used
   1. when the surname is two or more syllables long (e.g. %남궁_민 (Namkoong Min)), and
   2. also for mononyms (e.g. %_길동).
2. The personal name mode exists mostly because of RR. RR does not assimilate syllables in given names (e.g. 한복남 is "Han Boknam", not "Han Bongnam"; personally I don't like this, but that's how RR is). So whenever something is considered a given name, assimilation should be blocked (and the personal name mode takes care of this). I guess in most cases there is no difference, but cases like Seungri do make a difference ("seungni" not as a given name, but "Seungri" as a given name).
3. %길동 is surname 길 and given name 동. If there is no _ in the personal name mode, the single hangul syllabic block that immediately follows % is interpreted as the surname.
4. ^% is not valid because ^ (capitalization) should be only follwed by a hangul syllabic block. % (name mode) does capitalization automatically; it does not need ^.

172.56.232.154 (talk) 15:01, 26 May 2025 (UTC)

Ok, noted for now. I guess this is exactly why I had concerns about user-friendliness, now that I'm seeing how the implementation works in practice which is what I expected this in terms of UX. — Paper9oll (🔔 • 📝) 15:21, 26 May 2025 (UTC)

I kinda agree; think most people will struggle to grasp these nuances. I think it may be possible to have a checkbox option to indicate mononym name mode, but that's another parameter and more jargon.

Part of the issue is these problems are fundamentally complicated and user friendliness can only go so far. grapesurgeon (seefooddiet) (talk) 18:27, 26 May 2025 (UTC)