Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Option for hyphens in romanization #319

Open
thomasst opened this issue Jan 16, 2025 · 2 comments
Open

[Feature]: Option for hyphens in romanization #319

thomasst opened this issue Jan 16, 2025 · 2 comments

Comments

@thomasst
Copy link

Description

romanize should provide an option to use hyphens/dashes between syllables to clarify the syllable boundaries.

Possible Solution

function romanize(
  hangul: string,
  options?: { useHyphens?: boolean }
): string;

romanize('학여울'); // "hangnyeoul"
romanize('학여울', { useHyphens: true }); // "hang-nyeo-ul"

etc.

No response

@BO-LIKE-CHICKEN
Copy link
Contributor

BO-LIKE-CHICKEN commented Jan 17, 2025

I believe using the function multiple times in the context where it’s needed would be a better approach, as it keeps the function simple and focused.

If this option is truly necessary to enhance the user experience, I would suggest one of the following approaches:

1. Call the function multiple times

Instead of modifying the function or adding options, users can call the function for each syllable and add their own delimiters. This keeps the romanize function simple and leaves control to the user. For example:

const input = "학여울";
const result = input
  .split("") // Split into syllables
  .map(romanize) // Call the romanize function for each syllable
  .join("-"); // Add the desired delimiter

console.log(result); // "hang-nyeo-ul"

This approach allows the romanize function to remain clean and focused, while giving users full control over how to handle delimiters.

2. Add a function that returns an array of romanized syllables

Provide a new function (e.g., romanizeToArray) that returns an array of romanized syllables. Users can then decide how to handle delimiters:

const syllables = romanizeToArray("학여울"); // ["hang", "nyeo", "ul"]
const result = syllables.join("-"); // "hak-nyeo-ul"

This keeps the original function simple while adding flexibility for users who need advanced functionality.

3. Replace useHyphens with a more flexible separator option

Instead of a boolean flag (useHyphens), allow users to specify a custom separator:

romanize("학여울"); // "hangnyeoul"
romanize("학여울", { separator: "-" }); // "hang-nyeo-ul"
romanize("학여울", { separator: "|" }); // "hang|nyeo|ul"

This makes the function more versatile and adaptable for different use cases.

Summary

By calling the function multiple times (Option 1), users can maintain full control without complicating the romanize function. However, if a better user experience requires built-in functionality, Options 2 or 3 can provide additional flexibility while keeping the core function clean.

Let me know your thoughts!

@thomasst
Copy link
Author

Option 1: This produces different results (i.e. "hak-yeo-ul" instead of "hang-nyeo-ul"), which might not be desirable given that words should generally be romanized based on their pronunciation.

Option 2/3: For both of these, I am not sure if there is a need for separators other than hyphens (given that e.g. https://korean.go.kr/nkview/nknews/200105/34_3.html specifically mentions hyphens). Option 2 does indeed give the most flexibility here, though I am not sure if a new function is really necessary.

Eventually, I could also see romanize taking the romanization system as an argument, which could also be part of the options, but that's out of scope for this particular issue, e.g.:

function romanize(
  hangul: string,
  options?: {
    useHyphens?: boolean;
    system?: "RR" | "MR" | "Yale";
  }
): string;

I'm still leaning towards my originally suggested option, but options 2/3 are both fine if we wanted the separator to be customizable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants