안녕하세요, 프랑스어 Discourse 설치 환경에서 영어로 번역되지 않은 문자열이 점점 더 많이 발견되고 있습니다. 원인을 아시는 분 있으신가요? 감사합니다.
패트릭님, 안녕하세요
아직 이 항목에 대한 번역이 없는 것 같습니다. 직접 번역에 참여하고 싶으시다면, 여기에서 번역에 대해 자세히 알아보세요.
사실, 이전 Discourse 릴리스에서는 이 문자열을 포함한 여러 문자열이 프랑스어로 되어 있었지만, 최신 버전으로 업그레이드한 이후로는 더 이상 그렇지 않습니다.
브라질 포르투갈어 인스턴스를 운영하면서 저도 같은 느낌을 받습니다. 이 주제에 대한 최근 토론이 있었고, 제 추측을 언급한 바 있습니다.
https://meta.discourse.org/t/2-7-0-beta4-translation/181023/2?u=renato
예시를 방금 발견했습니다:
2021년 2월 12일에 봇이 영어 문자열에서 "these"가 "this"로 변경되었기 때문에 이전 번역을 삭제했다는 점에 주목해 주세요.
변경 사항이 중요하지 않다면 gettext처럼 이전 번역을 유지하는 것이 이상적이라고 생각합니다. 잘못된 복수형 표현이라도 영어로 된 전체 문자열이 나오는 것보다는 낫습니다.
스크린샷에 있는 문자열을 더 자세히 살펴보았는데, 해당 키가 코드 리팩토링으로 인해 이름이 변경되었습니다. 이는 예외적인 경우라고 추정하며, 이전에 존재했던 대부분의 번역 누락 사례는 원본 텍스트의 변경으로 인해 발생한다고 생각합니다.
@gerhard 이 옵션에 대해 조사해 보셨나요? 이메일 템플릿처럼 기존 번역을 사용하는 것이 치명적인 문제를 일으킬 수 있는 키가 몇 가지 있다는 점은 알고 있습니다. 하지만 일반적으로 기존 번역을 출발점으로 삼는 것이 아무것도 없는 것보다 나을 수 있습니다. 확신은 없네요… 여기에는 정말 많은 뉘앙스가 있습니다.
음, 보자. 여기에는 여러 가지 경우가 있습니다:
-
번역 키가 변경되는 경우: 우리는 이를 피하려 하지만, 때로는 단순히 불가능한 경우도 있습니다. 영어 문자열이 변경되지 않았다면, 기존 번역을 자동으로 사용하도록 Translation Memory™를 활용할 수 있습니다. Crowdin에는 정확히 그런 기능을 수행하는 “TM Pre-translation” 워크플로우 단계가 있습니다.
Translation Memory™를 사용하여 파일을 사전 번역하여 동일하거나 유사한 문자열의 번역 속도를 높입니다…
안타깝게도 이 방식은 번역자가 나중에 번역에 변경 사항을 가하는 것을 막습니다. Translation Memory로 번역된 문자열은 “Crowdsource” 워크플로우 단계를 거칠 수 없기 때문입니다. 이 문제를 오래전에 보고했지만, 아직 수정된 것으로 보이지 않습니다. 그래서 현재 우리는 "TM Pre-translation"을 사용하지 않고 있습니다. @Andriy_Crowdin 참고바랍니다.
-
수정된 영어 문자열: 어떤 것이 사소한 변경으로 간주되는 것일까요? 이는 어려운 결정이며, 언어에 따라 다를 수도 있습니다. 한 발 물러서서 생각해 보겠습니다. 기존 영어 문자열을 수정하면 어떤 일이 일어나나요?
- 수정된 문자열을 GitHub로 푸시합니다
- 번역자 봇이 이를 감지하여 Crowdin으로 푸시합니다
- Crowdin에서 해당 문자열의 모든 번역이 무효화되지만, 아직 Discourse의 번역에는 영향을 미치지 않습니다
- 매주 화요일 Crowdin에서 현재 번역을 가져와 GitHub로 푸시합니다.
- 누락된 번역은 제거됩니다
- 새로운 번역은 추가됩니다
따라서 화요일 바로 직전에 문자열을 수정한 경우가 아니라면, Crowdin에서 새 번역을 제공할 충분한 시간이 있을 것입니다. Crowdin의 제안 기능은 일반적으로 수정된 문자열을 번역하는 것을 매우 쉽게 만들어 줍니다.
-
기존 번역에 영향을 주지 않아야 하는 수정 사항: 영어 문자열에 사소한 일괄 변경을 할 때 기존 번역을 유지하는 것을 일반적으로 시도합니다. 예를 들어, 과거에
{{count}}플레이스홀더를%{count}로 변경하거나 영어 로케일 이름 변경을 할 때 그렇게 했습니다. 커밋 메시지에 추가할 수 있는 특수 명령이 있습니다:@discourse-translator-bot keep_translations_and_approvals @discourse-translator-bot keep_translations
실현 가능한 경우 워크플로우에 대한 개선 사항을 구현하는 데 기꺼이 참여하겠습니다. 그러나 Crowdin에는 ‘fuzzy’ 번역이라는 개념이 없습니다. 번역되었거나 안 된 것 둘 중 하나입니다. 그리고 저는 이것이 좋은 일이라고 생각합니다. 그렇지 않으면 단순히 일이 더 복잡해질 뿐이니까요. 번역자로서 새 문자열과 수정된 문자열에 대해 알림을 받으므로, 번역자가 상황을 파악하는 데 도움이 될 것입니다.
@patrickemin Translation Memory에서 누락된 프랑스어 번역을 추가했습니다. 오늘 업데이트에 포함될 것입니다.
어딘가에서 gettext가 유사도를 측정하기 위해 자로(Jaro) 거리를 계산할 때 기본 임계값으로 0.85를 사용한다는 것을 본 적이 있습니다. 완벽한 해결책은 없다는 점을 이해하고 있으며, 이는 이러한 변경 사항을 따라가기가 어려워 제안한 것일 뿐입니다. 저는 번역가가 아니며, 제 인스턴스에서 누락된 텍스트를 발견할 때마다 도움을 주지만, 기여도가 부족하여 Crowdin에서 제 언어의 “최상위” 번역가로 분류되고 있습니다.
불행히도 대부분의 언어에는 활동적인 기여자가 부족하며, 새로운 번역을 위해 일 주일은 충분하지 않을 가능성이 높다고 생각합니다. Crowdin에서 이메일을 받을 때마다 확인을 시도하지만, 제 언어는 이미 약 11,000개의 단어가 누락되어 있어 따라가기에 버거운 상황입니다.
번역 메모리(Translation Memory)™로 파일을 사전 번역하여 동일하거나 유사한 문자열의 번역을 가속화하세요…
언급된 수정 사항이 적용된다면 워크플로우가 실제로 개선될 수 있으며, 모호한 문자열(fuzzy string) 시나리오도 해결하는 것으로 보입니다.
사용자가 문자열을 로컬에서 커스터마이징하고 있다면 어떻게 됩니까? 이 경우에도 이미 문제가 아닌가요?
또 다른 가능한 대안은 기본적으로 무효화하지 않고, 의미가 완전히 변경된 경우 다른 워크플로우를 사용하는 것입니다. 예를 들어, 번역 키를 변경하거나 커밋 메시지에 @discourse-translator-bot invalidate_translations를 포함하는 방식입니다. 이는 번역 키의 의미 변경이 예외적인 경우라는 가정에 기반한 것입니다(이 가정이 완전히 틀릴 수도 있지만요).
그럼에도 불구하고, Crowdin은 정말로 작업하기가 편리합니다. 더 많은 사람들이 기여한다면 이러한 문제들은 발생하지 않을 것입니다. 많은 사람들이 텍스트 커스터마이징 기능을 번역 리소스로 사용하고 있다고 생각합니다.
그 사실을 인지하고 있습니다. 가까운 미래에 일부 언어에 대해 전문 번역가를 고용해 도움을 받을 수 있을 것이며, 브라질 포르투갈어도 그 목록에 포함되어 있을 것으로 생각합니다. 
또한 “Customize Text”(텍스트 사용자 지정) 및 기본 로케일 설정에 Crowdin 링크를 추가하는 방안을 고려하고 있습니다. 이를 통해 커뮤니티의 번역가들이 올바른 방향으로 안내받을 수도 있을 것입니다.
네, 맞습니다.