Request : Double-Byte characters need to be counted as 2

[TL-aalive]

Hello, I am from South Korea, and I'd like to thanks to this community for making such a wonderful program.

I am using SubtitleEdit to translate English to Korean. As you may know, Korean, Japanese and Chinese character set are Double-Byte based. And it causes us 'character counting' issues.

Since SubtitleEdit doesn't distinguish Single-Bye from Double-Byte, it counts '백' and 'B' as 1 character in counting.
But in reality, every OTT company requires Double-Byte characters to be counted as 1 and Single-Byte characters to be counted as 0.5.

Let me show you a Guideline from Netflix for 'Character Limitation' as below;
**2. Character Limitation

• 16 characters per line
• Latin characters, spaces, punctuation count as 0.5 character**
  ( Source : https://partnerhelp.netflixstudios.com/hc/en-us/articles/216001127-Korean-Timed-Text-Style-Guide )

The translators in Korea actually count the characters line by line to follow the Guideline and it is painful.

• Suggestion : Add option to count Double-Byte characters as 2, or count Single-Byte characters as 0.5

[niksedk]

Does the spec not say the Korean letters are counted as one? (probably a typo in the title?)

[TL-aalive]

I made an assumption that counting ASCII as 1 and CJK as 2 is easier than counting ASCII as 0.5 and CJK as 1. But I got confused when I wrote the idea. Any way, as long as ASCII : CJK keeps 1 : 2 ratio, either way is fine for me. Your current Beta CPS option looks good to me since we can sync with Netflix guideline of 16 characters per line.

[niksedk]

How does this work? https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip

You need to change "cps/line length style" first:

ping @TL-aalive

[TL-aalive]

The beta version is not working yet.
After set the CPS/line-length as above, the beta count drops to half of original version count as below.

BETA counts 4.5, It should count as 8.

Original version counts 9.

[TL-aalive]

It looks like the BETA counts all characters as 0.5

[TL-aalive]

Thanks a lot!I will get back to you once test this beta. It looks OK for me. 2022년 1월 24일 월요일 오후 02시 42분 32초 GMT+9, Nikolaj Olsson ***@***.***> 작성: How does this work? https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip You need to change "cps/line length style" first: — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>

[niksedk]

thx for testing :)
Beta updated to hopefully detect CJK chars better: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip

[LeonCheung]

Hmm, The default SE rule is like "Full-width 1, half-width 1". I think what @TL-aalive wants is "Full-width 1, half-width 0.5", simply a way to treat half-width character as 0.5. However, one problem I noticed for now is that when using the 3rd and 4th in the list ( CJK-related), at least Chinese punctuations (full-width) are also counted as 0.5, which is unexpected. Maybe the same case in Korean and Japanese?

For example, 你好，世界。 should be counted as 6 here, but it's 5 in beta 404:

[TL-aalive]

I cannot find beta 404. But in Korean, punctuations are single-byte(half-width) and should be counted as 0.5.
If you used "CJK 1, latin 0.5, space 0" option for that count, it will work for Korean.

[TL-aalive]

I found Japanese character limitation rule from Netflix as below.
So, in my opinion, Korean and Japanese could be counted in single option.

I.5. Character Limitation

Horizontal subtitles - Maximum 13 full-width characters per line
Vertical subtitles - Maximum 11 full-width characters per line
Full-width character, space, and punctuation counts as 1 character
Half-width character, space, and punctuation counts as 0.5 characters
(source : https://partnerhelp.netflixstudios.com/hc/en-us/articles/215767517-Japanese-Timed-Text-Style-Guide )

[niksedk]

OK, how is this: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip ?

Change set: 3831416

[TL-aalive]

This BETA 407 is same as 402. Can I get BETA 404 for test?

[niksedk]

Did you change the "line length/cps style" ?

[TL-aalive]

Yes, I did.

[LeonCheung]

@niksedk Ah, now it's expected. Chinese uses full-width punctuations (most of the cases). Here is a full list of full-width punctuations we use (totally 27, and the first two are just added in the last commit):

，。、：；？！…“”—‘’（）【】「」『』〔〕《》〈〉

[niksedk]

thx :)
Chars added here: c4602b2
And fix Japanese: 8e3aebe

[niksedk]

Beta updated: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip

@TL-aalive: Could you add the Korean text as plain text, if it still does not work?

[TL-aalive]

Those 24 Korean characters represent 10 vowels and 14 consonants of Korean alphabet. Hope this helps.

[niksedk]

OK, how is this beta: https://github.com/SubtitleEdit/subtitleedit/releases/download/3.6.4/SubtitleEditBeta.zip ?

Could write the Korean characters that does not work here on GitHub in plain text (and not in a screenshot).

[TL-aalive]

Oh! BETA 412 is perfect. Great work! Thank you!

• per your request, some Korean characters that didn't work in previous version

대한민국 활화산 동물들 천국의 섬 유독 춤을 춥니다

[niksedk]

Cool, and thx for testing :)

[TL-aalive]

Thanks to you! I asked my colleagues to test the BETA for further check. BTW when do you expect to release 3.6.5?