콘텐츠 로컬라이제이션 - Discourse AI를 활용한 수동 및 자동 처리

[nat (Natalie T)]

이 주제에서는 콘텐츠 로컬라이제이션(Content Localization) 기능과 이를 활성화하는 방법에 대해 안내해 드리겠습니다. 이 기능은 두 부분으로 나뉩니다: Discourse에서 기본적으로 제공되는 기능과, 자동 번역을 위한 Discourse AI입니다.

관련 섹션에 빠르게 접근하려면 위키 제목을 사용하세요

Discourse 호스팅을 사용 중이신가요?

이 기능은 귀하에게 제공됩니다! 커뮤니티에 이 기능을 설정하는 방법에 대해 자세히 알아보려면 계속 읽어보세요.

커뮤니티 콘텐츠 로컬라이제이션

Discourse는 다음 경로에서 설정할 수 있는 여러 로컬라이제이션 기능에 대한 접근성을 제공합니다:

• <your-site-url>/admin/site_settings/category/content_localization

사이트 설정의 콘텐츠 로컬라이제이션 📸

준비

먼저, 데이터 탐색기(Data explorer)를 통해 커뮤니티에 대한 정보를 얻는 것이 좋습니다.

사용자 설정을 통한 로케일(Locale)

다음 쿼리는 /my/preferences/interface에서 로케일을 설정했을 가능성이 있는 사용자 수에 대한 아이디어를 제공할 수 있습니다.

SELECT locale, count(*) as count
FROM users
WHERE (locale IS NOT null AND locale <> '')
GROUP BY locale
ORDER BY count DESC

데이터 탐색기 샘플 결과

사용자 유입 지역

Browser pageview events enabled(사이트 설정)이 활성화되어 있다면, 사용자의 국가를 알려주는 다음 쿼리가 더 나은 솔루션입니다:

SELECT
  e.country_code AS country_code,
  COUNT(*) AS pageviews
FROM browser_pageview_events e
WHERE e.country_code IS NOT NULL
  AND e.country_code <> ''
GROUP BY e.country_code
ORDER BY pageviews DESC

샘플 결과

설정

위 정보를 바탕으로 커뮤니티가 지원해야 할 로케일에 대해 더 잘 알게 되었습니다.

<your-site-url>/admin/site_settings/category/content_localization>에서 설정을 시작하세요.

• Content localization enabled - 원본 작성 사용자 콘텐츠를 로컬라이즈된 콘텐츠로 대체하는 기능을 활성화합니다. 로컬라이제이션의 자동(AI) 및 수동(인간) 모드에 대해 자세히 알아보려면 계속 읽어보세요.
• Content localization supported locales - 사이트가 지원하는 언어 목록
• Content localization crawler param - 아래 크롤러 섹션에서 설명합니다.
• Content localization language switcher - 바로 아래에서 설명합니다.

사이트 설정의 로케일 목록 📸

언어 전환기

이후 설정인 Content localization language switcher를 활성화하면, 지원 로케일 목록에서 선택한 언어 목록을 표시하여 로그인하지 않은 사용자에게도 커뮤니티를 더 접근 가능하게 만들 수 있습니다:

페이지 오른쪽 상단의 언어 전환기

로컬라이즈된 콘텐츠 보기

로컬라이즈된 콘텐츠의 시청자(모든 사이트 방문자)는 게시글 날짜 옆의 표시기에 커서를 올리면 게시글의 원본 언어를 볼 수 있습니다. 이 표시기는 게시글이 사용자의 언어가 아닐 때만 표시됩니다. 사용자는 표시기를 탭하여 원본 게시글도 볼 수 있습니다.

다국어 로그인 시청자의 경우, 여러 언어를 이해한다고 표시할 수 있으므로 해당 언어로 된 콘텐츠는 번역되지 않습니다.

Discourse AI를 통한 자동 번역

Discourse AI는 로컬라이제이션 기능에 매우 필수적이며, 수동 번역의 필요성을 제거합니다.

관리자로서, Translations(번역)을 위한 Discourse AI의 전용 영역으로 이동해야 합니다. 이 전용 영역은 다음을 포함합니다:

• 번역 진행 상황
• AI 설정
• 앱 언어 설정

중요한 설정 및 권장 사항 중 일부를 다루기 위해:

• AI translation backfill hourly rate - 이 설정의 기본값은 50입니다 - 사이트는 시간당 50개의 게시글, 50개의 주제, 50개의 카테고리, 50개의 태그를 Content localization supported locales에서 설정한 로케일로 번역합니다. 처음 시작할 때는 이 수치를 낮게 유지하세요.
• AI translation category scope - 기본값은 Public categories(공개 카테고리)입니다. 이를 모든 카테고리 또는 특정 선택으로 변경할 수 있습니다.
• AI translation personal messages 및 AI translation include bot content는 명백합니다.
• AI translation backfill start date - 이 값은 기본적으로 비어 있습니다. AI 번역 기능을 “오늘” 활성화하면, 날짜는 자동으로 "오늘 - 5일"로 설정됩니다.
• AI translation post raw translator agent(및 기타 에이전트) - 더 격식 있는 커뮤니티에서는 관리자가 자체 에이전트를 생성하는 것을 선택할 수 있습니다. 이렇게 하면 선호하는 언어나 어휘에 더 세밀하게 조정된 프롬프트를 설정할 수 있습니다.

적합한 에이전트를 구성하고 각 기능에 맞게 프롬프트를 미세 조정하는 방법에 대해서는 AI bot - Agents 를 참조할 수 있습니다.

수동 로컬라이제이션

로컬라이제이션은 Discourse의 핵심 기능이므로, Discourse AI를 통한 자동 번역이 사용 불가능한 경우 수동으로 로컬라이제이션을 입력하고 편집할 수 있는 기능을 제공합니다.

기본적으로 관리자와 모더레이터는 로컬라이제이션을 편집하도록 설정되어 있습니다.

현재, 게시글 콘텐츠, 주제 제목, 카테고리 이름, 카테고리 설명, 태그 이름, 태그 설명, 사이드바 로컬라이제이션을 가지고 있습니다. 아래 섹션에서는 이들이 어떻게 작동하는지 보여줄 것입니다.

카테고리 로컬라이제이션

로컬라이즈된 카테고리는 카테고리 이름과 설명이 모두 로컬라이즈된 상태로 다음 영역에서 표시됩니다:

카테고리가 로컬라이즈되는 장소들 📸

1. 홈페이지, 사이드바, 카테고리 드롭다운

2. 카테고리 페이지

3. 하위 카테고리가 있는 특정 카테고리

관리자로서, 평소와 같이 카테고리 설정에 접근할 수 있으며 왼쪽에 새로운 “Localizations”(로컬라이제이션) 내비게이션 항목을 찾을 수 있습니다.

카테고리 설정에서 카테고리 로컬라이제이션 편집 📸

주제 및 게시글 로컬라이제이션

위 카테고리 로컬라이제이션의 스크린샷에서 주제 제목과 발췌문이 로컬라이즈되는 것을 확인했을 수 있습니다.

일부 사전 요구 설정이 있습니다:

• 사용자가 content localization allowed groups에 있는지 확인하세요.
• Content localization enabled가 켜지면 addTranslation 버튼이 자동으로 post menu 및 post menu hidden items에 추가됩니다. 이를 통해 content localization allowed groups에 있는 사용자의 게시글 메뉴에 가 표시되도록 합니다.
• Content localization allow author localization은 기본적으로 활성화되어 있으며, 게시글 작성자가 위의 게시글 메뉴를 사용하여 자신의 콘텐츠를 로컬라이즈할 수 있도록 합니다.

게시글 메뉴 설정

로컬라이즈된 게시글 편집

사용자가 로컬라이즈된 게시글을 보고 있고 게시글을 편집하려는 경우, 어떤 버전을 편집할지 묻는 대화 상자가 나타납니다:

결정 후 적절한 컴포저가 나타납니다.

사용자 정의 사이드바 로컬라이제이션

"모두에게 표시됨"인 사이드바 섹션에는 추가적인 번역 컨트롤이 표시됩니다:

크롤러

Content localization supported locales에서 설정한 다양한 언어로 크롤러가 사이트를 볼 수 있도록 허용할 수 있습니다. 사이트 설정은 “Content localization” 섹션의 Content localization crawler param에 있습니다:

그 결과, 크롤러는 각 지원 언어가 각 주제의 head에 해당하는 hreflang을 가진 다음을 볼 수 있습니다:

추가적인 증거 / 검증용

이 기능을 광범위하게 테스트했으며, X개의 지원 언어를 도입한 후 올바르게 인덱싱되고 있음을 확인했습니다.

FAQ

설정을 마쳤지만 여전히 자동 번역이 작동하지 않습니다
다음 항목이 설정되었는지 확인하세요:

• Content localization supported locales에 최소 하나의 언어가 있는지
• Content localization enabled가 인지
  • Allow user locale이 인지 (기본적으로 활성화됨)
  • Set locale from cookie가 인지
• Ai translation enabled가 인지
• 각 번역 에이전트에 작동하는 LLM이 설정되어 있는지

모든 것이 실패하면 SiteSetting.ai_translation_verbose_logs를 활성화할 수 있습니다.

자동 번역은 저장되나요, 아니면 누군가가 주제를 볼 때마다 LLM에 전송되나요?
번역은 저장되며, 각 게시글은 언어당 한 번만 전송되고 번역이 재사용됩니다.

제 포럼이 영어와 일본어를 지원하고(Content localization supported locales를 통해) 있고, 누군가가 스페인어로 작성하면, 그들의 게시글이 번역되나요?
네. 작성된 언어와 관계없이 모든 주제와 게시글은 영어와 일본어로 번역됩니다.

원본 게시글이 편집되면 다시 번역되나요?
네 – 하루 최대 2회. 게시글이 편집되면 닌자 편집(ninja edits)을 고려하여 5분 또는 SiteSetting.editing_grace_period 중 더 긴 지연 시간 후에 재번역으로 전송됩니다. Content localization allowed groups의 권한 있는 사용자는 게시글을 즉시 재번역으로 전송할 수 있는 옵션이 있습니다.

에이전트나 LLM을 변경하면 번역이 삭제되나요?
아니요, 번역은 일반적으로 설정 변경에 걸쳐 유지되며, 게시글 메뉴 항목이나 번역 컴포저를 사용하여 명시적으로 삭제되지 않는 한 유지됩니다.

---

Discourse 호스팅을 사용 중이신가요?

지원 로케일 수는 귀하의 플랜에 의해 제한됩니다:

• Starter: 3
• Pro: 4
• Business: 5
• Enterprise: 10

시간당 백필(backfill) 한도는 현재 모두 100입니다.

[putty]

@nat

Category localization

As an admin, you should be able to access category settings as usual, and find the new “Localizations” nav item on the left.

Are there any recommendations for doing this in bulk for existing categories? Worst case, perhaps via API?

[nat (Natalie T)]

Hmm great question. I’ll see to it that API docs get updated for the category update endpoint.

[tvavrda (Tomas Vavrda)]

Will there be a support for per-language moderator (translator)? I am thinking about meta – where I might be volunteering for checking the posts in a specific language and manually update them. Especially documentation which may welcome some human touches. But you say only moderators can do it which I probably never be.

[nat (Natalie T)]

Hmm good suggestion. I think that can be done but we’ll need to think about the details on how it can be set up.

We currently have the following, but let me check if it can be extended to a group called “localization moderators”.

[Ivan_Rapekas]

@nat

ai_translation_backfill_hourly_rate is more than 12. This is a hidden site setting which requires console access.

How to access it? Could you provide a command please?

Does Sidekiq have any job linked? Is it possible to trigger it manually?

[Moin]

@Ivan_Rapekas

How to access it?

Using Hidden Site Settings

This is a how-to guide about Hidden Site Settings, how to enable them, and why you might want to adjust them. Required user level: Administrator Important: Console access is required for some steps. In Discourse, hidden site settings refer to configuration options that are not readily visible or accessible through the standard admin dashboard interface. These settings are part of the backend configuration that can control various advanced or potent…

[nat (Natalie T)]

@Ivan_Rapekas

@nat

ai_translation_backfill_hourly_rate is more than 12. This is a hidden site setting which requires console access.

How to access it? Could you provide a command please?

To add on to Moin’s post above, it’s just SiteSetting. ai_translation_backfill_hourly_rate once you get to the console. The job runs every five minutes and rate limit accordingly.

[putty]

I see localization is now available in the docs. Thanks @nat!

[satonotdead]

That’s wonderful, kudos to the team! I’m testing it right now and I will share my thoughts and overall experience.

*Moving from Discourse Translator plugin we miss Esperanto.

Can this 'simply‘ be added, or does it need to be built into discourse-languages first?*

[nat (Natalie T)]

@putty

localization is now available in the docs

Wow you’re on the ball – I was just about to report here.

@satonotdead

Moving from Discourse Translator plugin we miss Esperanto

… built into discourse-languages first?

Yes, kind of. We want a full localized experience where the controls (buttons, labels, etc) are translated properly and sufficiently (70% would be really good) via Crowdin (see Translations - Discourse Meta), and with that we can provide support to the language.

[tvavrda (Tomas Vavrda)]

Does the content localization work with Documentation Categories? It seems to me that sidebar content is not getting translated even though I localize the index topic.

Also I noticed a strange behavior. When I see a localized topic in the original language and I refresh, it switches to the localized version. I have to switch again to the original version manually.

[sam (Sam Saffron)]

Oh fantastic catch, yeah it is not working yet, but something @nat will track!

I wonder if this is a catalyst to coming up with a better abstraction / data model for the sidebar doc links.

[nat (Natalie T)]

@tvavrda

sidebar content is not getting translated

Yes that’s right – there are many places in Discourse that will need explicit translation, so I’m logging them as and when. Most recently, we localized notifications for topic titles as well. This is an example of a feature topic I created - Show translated user bios.

I’ll create a new topic and @ you so we make sure we cover all the bases in sidebar.

EDIT: @tvavrda covered here - Translate sidebar documentation links. Please have a look and see if it makes sense.

@tvavrda

Also I noticed a strange behavior. When I see a localized topic in the original language and I refresh, it switches to the localized version. I have to switch again to the original version manually.

What do you mean by “switch again”?

Do you mind sharing a video recording (include the address bar) next time it happens? Feel free to DM me for this case if the content is not suitable in public. Also, were you logged in? Technically speaking these things are tracked by cookies so it’s a bit puzzling for me.

[tvavrda (Tomas Vavrda)]

Sent you a video.

Another observation – I cannot see diffs of the translated content, right? That might be useful if there are updates to it. Not super important but it would make sense, I guess.

And another – the backlinks under the topic don’t show a localized topic name.

And a question: What’s the point of localizing category descriptions in the category settings? The category description should come from the localized version of the “About” topic, shouldn’t it? The localized version does not support markdown, so I cannot use a link, which I would like to.

Other than that it works beautifully!

[tvavrda (Tomas Vavrda)]

Well… the old GitHub - discourse/discourse-docs-sidebar · GitHub component actually respects the localization I temporarily switched to that one.

[nat (Natalie T)]

@tvavrda

I cannot see diffs of the translated content

Yeah, this is currently not supported as well and would be quite an endeavour.

We have a little special-coloured indicator (similar to post edits indicator next to it) when a translation may be outdated as the post version has changed.

[tvavrda (Tomas Vavrda)]

I also see an untranslated content on pinned topic’s abstracts. So I see a topic list in the translated language but the abstract of the pined topic shows original.

[Jagster (Jakke Flemming)]

We can manually do or fix translations, but can we manually trigger building of translations? Kind of on-demand job.

What I am thinking is I’ve allowed translation for a year old topics. But if that year is counted from current date, that limit will move all the time toward already translated content. But the biggest demand is older valuable content that I would like to reach fast and without quite slow bulk actions.

[ckshen]

I am curious, does anyone have any cost figures after turning on the translations? Our site has been around for a while, and whilst I’d like to translate the whole site if possible, cost is definitely a concern. so if someone has some rough idea of cost from your experience, e.g. 1000 posts resulting in a $1 cost, that’d help tremendously to get a ballpark cost idea.

Is the content localization done once then stored somewhere, i.e. not on demand? if so, is there anything that prevents me from firing up Ollama and some open source LLM on my desktop like Llama 3 or Deepseek 3 and just let the job run until its done?

Edit: I guess it may work to lower the initial translation cost, but it won’t work for newer posts unless one decides to keep the local LLM running perpetually.