perlmint / i18next-korean-postposition-processor

i18next post-processor for processing korean postposition

i18next-korean-postposition-processor

i18next post-processor for processing korean postposition - 을/를, 이/가, 은/는, 으로/로, 과/와, 이랑/랑.

This processor can handle korean character or arabic number(without decimal mark).

Setup

import processor, { KoreanPostpositionProcessor, default_testers, default_modifiers } from 'i18next-korean-postposition-processor';

i18next.use(processor);
i18next.use(new KoreanPostpositionProcessor());
i18next.use(new KoreanPostpositionProcessor({
    testers: [/* testers to use */, ...default_testers],
    modifiers: [/* modifiers to use */, ...default_modifiers],
});

Translation text

{{some_value}}[[를]] 수정했다.

i18next-korean-postposition-processor's Issues

Conflicting peer dependency: [email protected]

Hi @Perlmint,

First of all, thank you for creating the Korean postposition plug-in for i18next.

I'm in the process of using the plug-in to build an internationalization module for p5.js, a JavaScript graphical library. I'm trying to resolve the Conflicting peer dependency: [email protected] error, which I get from using i18next ^v19.0.2, and was wondering if there is a dependency update planned for the near future.

Thank you for your response in advance.

Customizable Modifier (exposing modifier)

Hello @Perlmint , First of all, Thanks for your amazing work!
We're trying to use this package for processing postpositions in our notification localization texts.

Currently, we uses html based string templates.
One of template looks like this: username님이 <b>#레드벨벳</b>을 좋아합니다.
so, actual rendered text will be:

username님이 #레드벨벳을 좋아합니다.

Anyway, current implementation treats enclosing character > as normal character.
So when template {{ username }}님이 <b>#{{ community }}</b>[[를]] 좋아합니다 with parameter { username: 'mooyoul', community: '레드벨벳' } will return mooyoul님이 <b>#레드벨벳</b>를 좋아합니다.

So i needed to strip enclosing tags from our input like this: balmbees@df4f3cc

I thought this is quick & dirty solution to solve our problem. (that's why i didn't open PR also) Many use-cases in near future will require creating additional modifier, if someone uses markdown in their template, they should strip markdown from their template like we did.

So i propose customizable modifier - Users should be able to add their own modifier.

import * as i18next from "i18next";
import KoreanPostProcessor from "i18next-korean-postposition-processor";

import * as stripTags from "striptags";
function htmlStripModifier(input: string) {
  return stripTags(input);
}

i18next
  .use(KoreanPostProcessor()) // default
  .use(KoreanPostProcessor({ // customizable
    modifiers: [
      htmlStripModifier,
      // add more modifier if needed
    ],
  }))
  .init();