Mudlet: 수정할 때 번역 손실 방지

해결 방법에 대한 아이디어가 있습니까? @crowdin

번역을 유지하거나 버리는 것 사이의 경계는 어디입니까?

번역을 TM에 다시 넣는 것이 가장 좋은 것 같습니다. 다시 꺼내기가 매우 쉽고 번역가가 텍스트를 재사용할지 여부를 결정할 수 있습니다.

정확히는 Crowdin의 스크린샷처럼 모든 문자열에 대해 개별적으로 해당 라인을 그려야 합니다.

번역가가 github에서 문자열을 가져온 후 팝업 대화 상자를 시작할 수 있는 옵션을 환영합니다.

지금 당장은 풀(pull)을 빠르게 수정하기 위해 이전에 어떤 문자열이 번역되었는지 구별조차 할 수 없습니다.

수정될 때마다 어떤 번역이 손상되었는지 조사하는 데 몇 시간을 보내는 것이 합리적이지 않다고 생각합니다.

Qt의 자체 Linguist(또는 오히려 lupdate )를 사용하여 소스 코드에서 직접 언어별 .ts 파일을 업데이트할 때 lupdate 에는 다음과 같은 옵션이 있습니다.

          Drop all obsolete and vanished strings.

해당 옵션이 제공 되는 경우에만 사용되지 않거나 더 이상 사용되지 않습니다. 이것이 CrowdIn 에서 주석 변경을 처리하는 방법입니다. 문자열이 .ts 파일에서 제거됩니다. 어떻게든 CrowdIn이 우리를 위해 그렇게 행동하도록 해야 합니다. :기도하다:

중요한 것은 주석 의 변경(동 명화 변경은 다를 수 있음)이 번역을 지워야 한다고 생각하지 않는다는 것입니다. "승인된" 상태를 잃는 것은 허용되지만 잊혀지는 것은 아닙니다.

안녕하세요 여러분,

리포지토리에 저장된 구성 파일( crowdin.yml )에 update_option 매개변수를 지정하여 CLI / API / GitHub를 통해 파일을 업데이트할 때도 수정된 문자열에 대한 번역을 저장할 수 있습니다.

더 많은 정보:
https://support.crowdin.com/configuration-file/#changed -strings-update

변경을 수행한 후 Crowdin에서 통합을 일시 중지 및 재개하여 변경 사항을 적용하십시오.

그것이 바로 당신에게 필요한 것이기를 바랍니다!

응답해 주셔서 감사합니다!

@Kebap 어떤 옵션을 원하세요?

고마워 얘들아. 이것은 굉장하다. 옵션을 자세히 검토합니다.

"update_as_unapproved" 옵션을 시도하고 싶습니다. 이것은 좋은 절충안인 것 같습니다. 번역은 그대로 유지되지만 승인 상태는 손실됩니다.

이제 이것을 테스트했을 때 작동하지 않는 것 같습니다. 문자열은 여전히 ​​번역을 잃었습니다. 위에 링크된 기술 자료 섹션에 제공된 예제를 정확히 반영하기 위해 구성 yaml 파일의 자동 생성된 간략한 레이아웃 을 향상시키기까지 했습니다.

그럼에도 불구하고 Crowdin은 불행히도 번역을 유지하고 승인을 제거하는 대신 단순히 문자열을 교체한 것 같습니다. 내가 잘못하고 있습니까?

문자열에는 이전에 번역 및 승인이 있었습니다(승인은 .ts 파일에서 보이지 않는 것처럼 보입니까?)

업데이트 옵션 "update_as_unapproved"는 짧은 yaml 레이아웃과 긴 yaml 레이아웃으로 모두 동일한 결과로 테스트되었습니다.

문자열(또는 주석)을 수정한 후 Crowdin은 이제 번역 및 승인 없이 수정된 문자열을 표시합니다.

Crowdin Diff는 문자열을 "유지되었지만 승인을 잃었음"이 아니라 "삭제 및 추가됨"으로 보고합니다.

-- 이 줄 위에 답장을 보내주십시오 --

        Hi everyone,

문제는 프로젝트에서 파일이 .html이고
.ts. 이러한 유형의 파일에는 명확한 KEY:VALUE 구조가 없습니다.
따라서 파일을 업데이트할 때 변경된 모든 문자열은
새로운 문자열로 간주됩니다. 시스템의 예상되는 동작입니다.
하지만 이것에서 할 수 있는 일이 있는지 개발자들에게 물어볼 것입니다.
그들이 사무실에 있는 경우!

내 대답을 어떻게 평가하시겠습니까?
좋다 [1] 좋다 [2] 좋지 않다 [3]

--
진정으로,
올가 쿠타
고객 성공 관리자

연결:

[1]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/1/
[2]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/2/
[삼]
https://secure.helpscout.net/satisfaction/204306672/record/1818790773/3/

    > On Sat, Sep 8, 2018 at 1:34:23 EEST, Mudlet/mudlet <[email protected]> wrote:

"update_as_unapproved" 옵션을 시도하고 싶습니다.
좋은 절충안: 번역은 그대로 유지되지만 승인된 번역은 손실됩니다.
상태.

이제 이것을 테스트했을 때 작동하지 않는 것 같습니다. 여전히 손실된 문자열
그들의 번역. 나는 심지어 자동 강화까지 갔다.
구성 yaml [1] 파일의 간단한 레이아웃을 만들었습니다.
기술 자료 [2] 섹션에 제공된 예를 정확히 반영
위에 링크.

여전히 Crowdin은 불행하게도
번역을 유지하고 문자열을 제거하는 대신
승인. 내가 잘못하고 있습니까?

문자열은 이전에 번역 및 승인을 받았습니다(승인은
.ts 파일에서 보이지 않습니까?)
[삼]

업데이트 옵션 "update_as_unapproved"는 짧고 길게 테스트되었습니다.
yaml 레이아웃, 둘 다 동일한 결과
[4]

문자열(또는 주석)을 수정한 후 Crowdin은 이제 수정된 것으로 표시됩니다.
번역 및 승인이 없는 문자열
[5]

Crowdin Diff는 문자열을 "보존되었지만 추가됨"이 아닌 "삭제 및 추가됨"으로 보고합니다.
승인을 잃었다"
[6]

-
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub [7]에서 보거나 음소거
스레드 [8].

연결:

[1] https://github.com/Kebap/Mudlet/blob/crowdin-test/.crowdin.yml
[2]
https://support.crowdin.com/configuration-file/#changed -strings-update
[삼]
https://user-images.githubusercontent.com/117238/45245753-12b3a300-b2fe-11e8-819a-fbc1cab389cd.png
[4]
https://user-images.githubusercontent.com/117238/45245828-632b0080-b2fe-11e8-8457-d16f53e62976.png
[5]
https://user-images.githubusercontent.com/117238/45245723-e7c94f00-b2fd-11e8-831d-14f3c0151aa8.png
[6]
https://user-images.githubusercontent.com/117238/45245651-843f2180-b2fd-11e8-8744-b431244e39e8.png
[7]
https://github.com/Mudlet/Mudlet/issues/1961#issuecomment -419583856
[8]
https://github.com/notifications/unsubscribe-auth/AA0k1tqzDWWwb2qGudFk9ENRg7Hm3D-Hks5uYvRcgaJpZM4WeaRq

예, Qt IDE 는 .ts 파일을 사용합니다. 확실히 이것은 틈새 시장이 아닙니다. Crowdin 개발자의 추천이 있습니까?

Qt의 피드백은 결정적이지 않았습니다.

(케밥) 안녕하세요 여러분! 번역 및 번역가를 처리하기 위해 웹 기반 서비스 웹사이트를 사용해 본 사람이 있습니까? 우리는 Crowdin을 사용하며 Qt .ts 파일 형식에서는 잘 작동하지 않는 것 같습니다. 그들은 수정된 모든 문자열이 새로운 문자열이라고 생각하고 오래된 번역을 삭제할 것이라고 생각하는 것 같습니다. 자세한 내용은 다음 스레드를 참조하세요. 이 문제를 어떻게 해결할 수 있습니까? https://github.com/Mudlet/Mudlet/issues/1961
(frkleint) Kebap: http://lists.qt-project.org/mailman/listinfo/localization 메일링 리스트에 게시하는 것이 좋습니다.
(Kebap) 그 메일링 리스트는 번역 Qt 프로젝트 자체에 관한 것 같습니다. 그러나 Qt로 자신의 프로젝트를 구축하고 다른 언어로 번역하는 다른 사람들이 있습니까?
(frkleint) Kebap: 예, 하지만 올바른 관리자/사람들이 읽을 것입니다.

모든 세부 사항을 다시 확인하겠습니다. @Kebap. 내 머리에는 하나의 "플랜 B"가 있지만 테스트해야 합니다.

소스 텍스트/번역을 저장해도 될까요? .ts 파일의 요소? 에서 예를 들어 고유한 문자열 ID를 가질 수 있습니다.

현재 CrowdIn에 대한 소스 텍스트가 포함된 mudlet.ts 파일을 가져오거나 업로드하고 mudlet_xx_YY.ts 를 생성하도록 처리합니다. 여기서 xx 는 두 글자 언어 코드이고 YY 입니다. mudlet.ts 는 Qt lupdate 유틸리티로 생성/업데이트된 것으로 생각합니다. 이 유틸리티는 ./translations lupdate -locations absolute ../src/mudlet.pro -ts ./mudlet.ts {at 최소한 *nux OS}에서.

대안이 있지만 CrowdIn이 개별 .ts 파일(현재:

• mudlet_de_DE.ts
• mudlet_el_GR .ts`
• mudlet_en_GB.ts
• mudlet_es_ES.ts
• mudlet_fr_FR.ts
• mudlet_it_IT.ts
• mudlet_nl_NL.ts
• mudlet_pl_PL.ts
• mudlet_ru_RU.ts
• mudlet_zh_CN.ts
• mudlet_zn_TW.ts

) 파일을 CrowdIn에 업로드하고 번역 팀에서 작업하도록 합니다. 그러면 기존 번역 작업 이 각 .ts 파일 내에서 유지됨 을 의미합니다. 이것은 실제로 Qt에서 번역이 수행될 것으로 예상하는 방식입니다. 왜냐하면 lupdate 가 변경 사항으로 각 개별 번역 파일을 업데이트하기 때문입니다. 실행될 때 코드 소스에서 가져오지만 더 이상 소스에 나타나지 않는 오래된 텍스트를 버리지 않습니다( -no-obsolete 인수로 명시적으로 지시하지 않는 한). 이것의 단점은 CrowdIn 시스템 과 혼동하거나 작동하지 않을 수 있는 모든 번역에 대한 단일 소스 파일이 없다는 것입니다. 장점은 복수형 전용 mudlet_en_US.ts 파일을 생성하고 릴리스/버전/무엇이든 변경될 때 CrowdIn에 업로드할 때 포함할 수 있으므로 #1963 즉시가 문제가 되지 않는다는 것입니다.

Crowdin은 입력으로 단일 파일이 필요하다고 생각합니다. 설정하는 동안 여러 파일을 좋아하지 않는다는 것을 기억합니다. 즉, 문제는 입력 및 출력 파일이 동일하다는 것이었습니다.

입력 및 출력 파일의 이름을 다르게 지정할 수는 있지만?

Crowdin은 번역할 다른 문자열에서와 같이 여러 입력 파일을 확실히 처리할 수 있습니다. 그러나 SlySven의 계획에서는 모두 동일한 내용을 갖습니다. 즉, 폴란드 번역 팀도 mudlet_it_IT.ts 및 mudlet_ru_RU.ts 등을 포함한 모든 파일을 볼 수 있음을 의미합니다. 따라서 우리는 그 길을 더 많이 진행하지 않고 대신 하나의 중앙 번역 파일을 선택했습니다.

편집: .ts 파일 생성에 대한 설명은 정확하지만 사용된 실제 명령은 다음과 같습니다. lupdate -recursive .\src\ -ts .\translationsmudlet.ts

Vadim이 무엇을 의미하는지 잘 모르겠지만 Kebap이 같은 경로에 있다고 생각합니다. 모든 파일을 입력할 수 있지만 그런 다음 CrowdId에게 세트의 mudlet_ru_RU.ts 만 표시되어야 한다고 말/알리는 방법은 무엇입니까? 러시아어(러시아) 번역가?

@vadi2 맞습니다 . 단일 소스 파일을 업로드하는 것이 좋습니다. Crowdin은 자체적으로 번역된 파일을 생성합니다.

mudlet_ru_RU.ts 와 같은 파일을 프로젝트에 업로드하지 마십시오.

아마도 우리는 그것에 대해 더 논의하기 위해 전화를 걸 수 있습니까? andriy(at)crowdin.com으로 연락주세요.

나는 확실히 효과가 있을 한 가지 아이디어를 염두에 두고 있지만, 당신이 그것에 만족할 것인지 들어봐야 합니다. 문제는 .ts에는 각 문자열에 대한 고유 식별자가 없다는 것입니다. .po에서와 같이 msgid 는 소스 및 식별자이고 <source> 는 텍스트 및 식별자이기도 합니다. ( <context> 및 <name> 요소와 함께 각 문자열은 고유한 것으로 간주되며 <source> 를 수정하면 문자열이 새로운 것으로 간주되고 수정된 것에 대한 번역을 유지할 수 없습니다. 결과의 문자열).

어쨌든, 팀에 논의/시연하고 싶은 꽤 좋은 솔루션/해결 방법이 있습니다. ;)

... 소스의 텍스트와 같은 일부 콘텐츠만 동일하지만 각 로케일에 대해 이미 수행된 번역도 해당 파일에 저장되며 다음 업데이트-번역 주기마다 표시됩니다.

고유한 메시지 식별자 체계가 Qt 시스템에서도 허용되지만 작업하기가 더 어렵다는 것을 이해한다면 - 그리고 프로젝트 중간 변경은 사소한 작업이 아닙니다(두 시스템은 상호 배타적이며 매우 좋은 방법론이 필요합니다 의미 있는 식별자를 찾기 위해) - 기존 체계의 이점 중 일부는 중복 문자열이 단일 공통 번역으로 병합된다는 것입니다. 같은...

한 언어의 모든 문자열을 100%로 번역한 다음 릴리스에서 일부를 편집할 때 TM 덕분에 계속 살펴보고 다시 추가하는 것이 여전히 쉽지 않을까요?

이 문제는 아직 100%에 도달하지 않았기 때문에 실제 문제처럼 보입니다.

@vadi2 TM의 도움으로 새로 추가된 문자열을 자동으로 번역하는 기능을 원하는 경우 고급 워크플로 기능을 사용하여 이러한 워크플로를 설정할 수 있습니다(귀하의 계정에서 방금 활성화했습니다)
https://support.crowdin.com/advanced-workflows/

감사합니다 :) 우리는 이것을 연구할 것입니다.

@Kebap 은 다음과 같이 썼습니다.

편집: .ts 파일 생성에 대한 설명은 정확하지만 사용된 실제 명령은 다음과 같습니다. lupdate -recursive .\src\ -ts .\translationsmudlet.ts

-recursive 는 기본 인수의 경우이며 필요하지 않습니다. 새 파일에 대한 -locations absolute 도 분명히 마찬가지입니다... :slightly_smiling_face: - 어떤 효과가 있는지 확인하는 동안 이 사실을 알게 되었습니다. lupdate 문제는 여전히 C++11/14 원시 문자열 리터럴 { QTBUG , #1310} 및 mudlet.ts 파일에서 문자열이 혼란스러워서 손실되는지 여부입니다. . : 인상을 찌푸리다:

@Kebap 이게 아직도 문제야?

예, 변경 전만큼 나쁘지는 않지만. 그러나 일주일 전의 연결된 문제에서 알 수 있듯이 초보자에게도 여전히 혼란 스럽습니다.

또한 현재 대부분의 언어가 아직 100%에 가깝지 않은 동안 약간의 경쟁이 있습니다. 다시 번역을 느슨하게 하는 것보다 문자열을 더 빨리 번역할까요?

게다가 삭제된 번역을 다시 불러오는 것처럼 보이는 문제를 발견했습니다. 현재 Crowdin에서 번역을 삭제할 방법을 찾지 못했습니다. 다음 업데이트 이후에는 자동으로 다시 추가됩니다.

@Andrulko 여기에 업데이트가 있습니까? 위에서 플랜B를 말씀하셨는데..

또한, Crowdin이 지금 TM에서 이 이상한 행동을 하는 이유는 무엇입니까!? 비교를 위해 아래 스크린샷을 참조하십시오.

여기서 우리가 변경한 것은 h3 에서 a 로 변경되었습니다. 다른 태그는 건드리지 않았습니다. 이제 무슨 일이?

번역가가 모든 {[=-lt;-=]}h2{[=-gt;-=]}{[=-lt;-=]}u{[=-gt;-=]} 를 <h2><u> 또는 <0> 수동으로 대체하기를 기대하시겠습니까?

예제 링크: https://crowdin.com/translate/mudlet/137/en-de
예의 스크린샷:

Crowdin의 TM에 있는 버그라고 생각합니다. 그들에게 별도의 문제로 보고하는 것이 가장 좋습니다.

여기에서도 알렸습니다: https://crowdin.com/contacts

안녕하세요, 귀하의 요청을 이미 확인했으며 귀하의 이메일에 회신했습니다. 다른 질문이 있으면 알려주세요!