Forum rules
Under no circumstances is spamming or advertising of any kind allowed. Do not post any abusive, obscene, vulgar, slanderous, hateful, threatening, sexually-orientated or any other material that may violate others security. Profanity or any kind of insolent behavior to other members (regardless of rank) will not be tolerated. Remember, what you don’t find offensive can be offensive to other members. Please treat each other with the kind of reverence you’d expect from other members.
Failure to comply with any of the above will result in users being banned without notice. If any further details are needed, contact: “The team” using the link at the bottom of the forum page. Thank you.
User avatar
eduo
Posts: 716
Joined: Sat Feb 10, 2007 1:40 am
Location: Information Technology
Contact: ICQ Website Yahoo Messenger

Re: guidelines for subs

Tue Jul 31, 2012 12:56 am

"For example"
For example, it says to use “I’d” instead of “I should” – something that makes no sense in any language except English. Or its use of quotes follows English rules. In Slovak we don’t write “Ahoj” but „Ahoj“ so why should we use a different system for our subtitles? And we never use single quotes.

Also, its talk about 180 words per minute may be true for English, where most words are short, one or two syllables. But most European languages use much longer words, or rather a combination of some short and many long words. So the speed of reading cannot be the same, in words per minute, as in English.

It is also often impossible to make both lines of equal length precisely because of a long word in the middle of the sentence.

We also have strict rules about placing a comma (while English is fairly free about using them). We would be breaking the rules of our orthography if we skipped a comma at the end of a subtitle and replaced it with three dots.

And we really hate it when someone who knows nothing about our rules wants to impose foreign rules on our language. As I’m sure English speakers would be annoyed if a Slovak insisted they use Slovak rules (or the rules of any other foreign language).
I'm sorry, I wasn't clear. I was quoting myself. The link was an example of the type of rules I was referring to. It'd be idiotic to try and come up with hard rules that apply to every language in the world and I would never attempt to do so.

There's no need, I feel, to have a single set of rules that applies to all languages but to have rules that apply to each in the same way. Some languages can't work with just 35 characters per line, others can be made faste. The point is that rules for subtitling shouldn't be subjective (or, rather, shouldn't be completely subjective). They should (and in reality they are) be clear and specific.

I have worked as a professional subtitles for spanish, portuguese and english. In all cases the rules are strict and enforced, but they're not identical. They do resemble each other because the underlying theory is the same for all. Rules for english can specify whether contractions are valid because in english contractions carry a clear contextual message. For spanish on the other hand there's no equivalent so it's not even mentioned, but BOTH have rules for length per line, lines per page, reading speed and minimum delays, etc. Then each language has its own rules that apply only to it.

There's no point arguing whether uppercase should be accented in cyrillic just because it's a hard rule in spanish. It's irrelevant in any discussion as would be pretending to apply english rules to non-english languages.

Nobody pretends to "impose foreign rules", but to give an example on why the rules linked before are all good and well, but too subjective and generic to be enforceable. Clearer rules need to be defined if there's any hope of anyone following them properly.
http://eduo.info/
[url=http://eduo.info/soleol/]OpenSubtitles from your desktop: SolEol for Mac/Windows/Linux[/url]
[url=http://forums.plexapp.com/index.php?showtopic=325&st=0&p=2480&#entry2480]My current episode processing work flow[/url].

srtpal
Posts: 59
Joined: Sun Jun 21, 2009 5:28 pm

Re: guidelines for subs

Tue Jul 31, 2012 1:29 am

Well, the http://www.bokorlang.com/journal/04stndrd.htm link purported to propose the rules for European subtitles. And there are many countries and many languages in Europe (heck, some of us do not even feel England is in Europe but near Europe from which it has been separated for most of its history by water).

User avatar
eduo
Posts: 716
Joined: Sat Feb 10, 2007 1:40 am
Location: Information Technology
Contact: ICQ Website Yahoo Messenger

Re: guidelines for subs

Tue Jul 31, 2012 1:42 am

Well, the http://www.bokorlang.com/journal/04stndrd.htm link purported to propose the rules for European subtitles. And there are many countries and many languages in Europe (heck, some of us do not even feel England is in Europe but near Europe from which it has been separated for most of its history by water).
Which is exactly why I decried it as useless from a practical standpoint. It's paramount to someone telling you "drive well in every country" and considering that enough rules to drive around everywhere. It's valid, it's defendible and it's admirable, but it's unenforceable, unmeasurable and impractical.

Those guidelines are made for people who work professionally in this. Subtitles of the kind OpenSubtitles hosts and shares, on the other hand, are made by people who're more enthusiastic than anything else, and who may not realize the importance of some rules that professional translators and subtitlers may take for granted. So rules for professional subtitlers may have the luxury of being a lot more vague than rules for hobbyist translators (who, by the way, are usually the root cause we're always discussing having rules in the first place).

Having generic rules that sort of imply you already know the basic rules is exactly the sort of solution the problem of having careless, ignorant, lazy or over eager subtitlers can't be solved with.

In my case I consider it a sin to put html tags in subtitles. No exceptions. As there's no rule for italics that works across players then unless I'm using a format that supports them, italics are out of the picture. I may use asterisks if necessary but never, ever, html (which is a bad hack on top of the already-dumb SRT format).
http://eduo.info/
[url=http://eduo.info/soleol/]OpenSubtitles from your desktop: SolEol for Mac/Windows/Linux[/url]
[url=http://forums.plexapp.com/index.php?showtopic=325&st=0&p=2480&#entry2480]My current episode processing work flow[/url].

srtpal
Posts: 59
Joined: Sun Jun 21, 2009 5:28 pm

Re: guidelines for subs

Tue Jul 31, 2012 2:47 am

Having generic rules that sort of imply you already know the basic rules is exactly the sort of solution the problem of having careless, ignorant, lazy or over eager subtitlers can't be solved with.
No argument from me. :)
In my case I consider it a sin to put html tags in subtitles. No exceptions. As there's no rule for italics that works across players then unless I'm using a format that supports them, italics are out of the picture. I may use asterisks if necessary but never, ever, html (which is a bad hack on top of the already-dumb SRT format).
Again, no argument. I do not use the HTML tags in SRT either.

Another problem with SRT is that SubRip saves the SRT files either in ANSI or in 16-bit Unicode. OS rejects the 16-bit Unicode, so I always convert mine to UTF-8 before uploading.

But, while VLC can handle both, Unicode and UTF-8, just fine, TotalMedia Theatre 5, a commercial video player, expects SRT to be either in 16-bit Unicode or ANSI. If you throw UTF-8 at it, it treats everything as ANSI and shows all the UTF-8 encoded non-ASCII characters as ANSI and displays them, so it is a real mess.

So, I have to keep two sets of each subtitle file, one in UTF-8 for OS, one in 16-bit Unicode for TotalMedia Theatre 5.

2Hb

Re: guidelines for subs

Tue Feb 19, 2013 6:36 am

Not to repeat the issue yet again, but here is the point.
The below quoted is from some earlier post of some of yours, and it makes some sense to me.
I have read the threads (here and there) before and after I made the long one line rule by myself. They made me more sure about my rule being most reasonable among all other customs on the issue.
for example, keeping lines to a maximum of 40 chars. But what if a line becomes 41 chars? And what if it is 44 chars? 50? One has to decide what to do, and make some kind of 'optimum-decision'. I am talking about the conflict between the number of characters, the time one has to read that line, the readability decrease when it is split by a hard return (the eyes will have to travel), or -even worse- by a completely new line (the yes will lack an 'overview'), or taking away some of the original meaning.

And what about hard returns? Look:

(40/15)
I can split one long line into two lines
after ch #40.

or

(30/31)
I can split one long line into
two more or less equal lines.

What is nicer to read..?
This all happens because our tastes differ. So, no matter what standard you set, there must be a complaint about it.
When you break a line at certain point, there is no way to put back them to one line on the fly while playing.
That is where one line (superiority) theory comes in. Remember, one line is not always one line. It can be two lines when smart-wrap automatically kicks in. That is the strength of one line rule. The way how smart-wrap works is very smart. There are three options to choose. They are: 1) Smart-wrapping, lines are evenly broken, 2) End-of-line word wrapping, and 3) Smart-wrapping, lower line gets wider.
See these samples: they are wrapped by the setting accordingly. This is just a sample line of 45 characters.
1)
Image
2)
Image
3)
Image

The effect is more apparent when the number of character gets larger, say 89 like the following sample.
1)
Image
2)
Image
3)
Image

Unless you stop breaking lines and make them just as one line, there are always someone who complain of the way how you break lines.
However, by one line policy with proper setting in a certain player software (video decoder - ffdshow for MPC to be precise), the issue is mostly resolved. I have to say "mostly" here, because there might be someone who still do not satisfy with these three options besides one long line. For those few exceptional ones, I have to say you do on your own.

Now, let us review this once again.
Suppose the people who prefer (40/15) style as type-A, (30/31) people as type-B, and (15/44) people as type-C.
Type-C people supposedly prefer this style:
(15/44)
I can split one
long line into two more or less equal lines.

If type-A subtitler break every line at 41th character, then type-B people complain the lines are not even and type-C people complain the first line is too long.
If type-B subtitler break every line just in middle, then type-A people complain the second line is too long and type-C people complain the first line is too long.
If type-C subtitler break every line at 16th character, then type-A people complain the second line is too long and type-B people complain they are not even.
Why does this all happen? Because once you break a line, there is no way to put them back and re-break in another way automatically.
When a line remains as it is at the time of playing, at least three types of breaking as well as just one line are all possible automatically.
This is the strength of one line rule.
I do not see why there are people who are strongly against this idea.

Just to be sure, I am not saying a line should be longer. Where you break a line and make the rest as another part (not as the second line) is up to you. I am just talking about whether or not a line in a part should be broken. Line length itself is not the matter here. When a line is too short like 25 characters, there is no such problem. But once it is over like 30 or so, there are always someone who complain because the line would be broken in the way they do not like.
I personally do not care if a line is 150 characters long, but that does not have to do with one line policy itself. I just prefer one line with many characters with much more time.

User avatar
jcdr
Posts: 540
Joined: Sun Apr 08, 2012 9:49 am

Re: guidelines for subs

Tue Feb 19, 2013 9:33 am

2Hb, indeed when using ffdshow, you are certainly right: it is better not to break the lines and adjust the best subtitles mode which suits you.
But keep in mind that on Windows OS, 70% of users use VLC player, whereas only 15% use MPC-HD. And there is a substantial number using Mac or Linux, who cannot use ffdshow.

Also, many users as myself watch the videos on their television, either via HDD media interface (eg WD TV Live), or by directly plugging a USB flash memory into the TV USB port. There is generally absolutely no control over the size of subtitles, or breaking of the lines.

So the rule for breaking subtitles is made to cope with the greatest number of users -not to cope with the few using ffdshow on their Windows PC.

User avatar
SimplyTheBOSS
Site Admin
Posts: 1326
Joined: Mon Feb 01, 2010 3:02 pm
Location: Finland

Re: guidelines for subs

Thu Feb 21, 2013 12:35 pm

2Hb, indeed when using ffdshow, you are certainly right: it is better not to break the lines and adjust the best subtitles mode which suits you.
But keep in mind that on Windows OS, 70% of users use VLC player, whereas only 15% use MPC-HD. And there is a substantial number using Mac or Linux, who cannot use ffdshow.

Also, many users as myself watch the videos on their television, either via HDD media interface (eg WD TV Live), or by directly plugging a USB flash memory into the TV USB port. There is generally absolutely no control over the size of subtitles, or breaking of the lines.

So the rule for breaking subtitles is made to cope with the greatest number of users -not to cope with the few using ffdshow on their Windows PC.

Exactly, regular users just want to watch, they don't want to adjust the settings, change the player or fix the subtitles etc. I did a few tests with with different settings using ConvertXtoDVD, I didn't get proper result. I wonder how those subtitles work on Boxee for example, maybe os have tried? What about the players which download subtitles directly from the website? In the end, there are good reasons for standards.
Image

User avatar
SmallBrother
Site Admin
Posts: 3724
Joined: Sun Mar 04, 2012 12:59 pm
Location: Somewhere on this globe

Re: guidelines for subs

Fri Mar 29, 2013 7:36 pm

2Hb,

You do have a point and in some cases your method has advantages. But it is not just superior over other methods and surely has disadvantages too.

A very important one is the fact that most people are not like you :wink: As Jcdr and STB already pointed out, most people do not use your software and are not able/willing to make all kind of settings. How silly or whatever this may seem or even be, it is the reality. And therefore it is the reason why some are against your method: it rules out the majority.

Another disadvantage of your method is that the break is purely calculated by the number of characters (whether it is the A, B or C method). Personally I prefer to keep word groups together (as long as it doesn't get too much out of hand).
For example (18+31):
I don't understand
why he left so early yesterday.

or (38+18):
I really don't have the slightest idea
where he could be.

This is not done by calculating the characters, but by a human who understands the meaning of the text. In fact, your method/software/settings would never be able to achieve this.
I do not see why there are people who are strongly against this idea.
You gave the answer already:
no matter what standard you set, there must be a complaint about it.
:wink:
Nowadays a VPN is a must for everyone. A VPN allows you safe surfing and protects you against spying governments and companies.
I advise AirVPN - from € 2,75 per month. Click the below banner for more info.


Image

User avatar
hector
Posts: 370
Joined: Wed Jan 01, 2014 12:27 pm
Location: Spain

Re: guidelines for subs

Mon Jan 12, 2015 7:08 pm

Very interesting.

Yes, life is tough. But only if you take it so. I mean, if you try to do your best. Some people prefer to take it easy. Subtitling is like anything else in life.

About rules, I think there are some which are indisputable. There's always some trade-off between subtitle length, reading time,
information amount, legibility, and so on.

I think it's good to have two line subtitles because one line would make them too short in time, i. e. they'd change too fast.

About line breaks, I always give prefer legibility to equal line length. For example, I think it is better:

It's not catching,
but I've got just five or six months to live.

than

It's not catching, but I've got
just five or six months to live.

I think it's preferable to keep sentences together. But it can be a matter of taste.

About the dots in a split line, I just don't like them. I think they don't add anything and I find them even annoying. You can
deduce that something is a continuation from the meaning and context. There are punctuation marks to separate sentences.
I only use horizontal ellipsis (...) for that, i.e. when somebody leaves a sentence unfinished.

Anyway I think it is important to keep in mind the target of the subtitle. Aside from language, you don't write the same for hearing people or for hearing impaired. The second must get much more information: emotions, who is speaking, and so forth.

I wouldn't say "rules" but guidelines. So, if I write one three line subtitle in a film, I don't think it can be labeled "wrong". Perhaps it's preferable to give all the information in one subtitle than showing two hasty ones or lose some important content.

About, HTML tags, I think the main problem is that usually you don't know what can or cannot be done. You can use <i> or <b> but I don't think there is some sort of format specification so you don't have any guarantee that the user will see what you want him to see. SRT is not a very well-defined format. I think we need something more well-defined like WebVTT or TTML. I think it is a good way of adding information (for example for hearing impaired) without stretching the subtitle length.

User avatar
hector
Posts: 370
Joined: Wed Jan 01, 2014 12:27 pm
Location: Spain

Re: guidelines for subs

Mon Jan 12, 2015 7:24 pm

Another interesting issue we can talk about here is user preferences.

From my experience I think it is good to give the users the last word: the user is always right. If he prefers equal length lines over sentences together, he should be able to get it. That is a matter of the software developer.

Anyway I think it is also good to have a good original document. Good formatting, good translation... "Good" interpreted from the author's point of view. That is a matter of the author: to give some quality. So the author says: this is what I think is best for you. Then the user is free to take this as is or override whatever he/she wants.

kerremelk
Posts: 82
Joined: Sun Jan 12, 2014 2:47 pm

Re: guidelines for subs

Fri Jan 23, 2015 10:47 pm

Hi...
One way or another, I aways see "colour marked" problems while I use 'subtitle edit'.
I also see that OCR creates/solves problems when one uses italicised scan ticked ON or OFF.
ON, it puts italic triggers where they do not belong. (and often puts wrong accents where there are none.)
OFF, it often scans txt better, but then it leaves out italics where there were large portions of it in the original.

What's worse.
One should realise that Dutch rules for diminutives creates problems...
That our very misunderstood rules for dt, double t, double d, in 'par example' verwoordde'... gets you unknown words.

And that the incompleteness, or perhaps overlap in the existing lists with known words often create a helluva mess.
That is just the tip of the icebergh of scan errors one encounters when one scans an IDX/SUB one ripped from retail dvdees.
Of course, one can add words to the user replace exeptions, user word list, user names list.
But...
After a while one really has to edit those lists, because the main rules in the programme would then find that this "OCR fix guess" gets no preference over what is in the "holy" area of the programme.
In other words, the fixing rule you tried to make sometimes has no effect, and sometimes it creates additional problems.

While subtitle edit is a great programme, it will automatically change 't to 'T if that 't is at the beginning of a sentence.
In English, that's okay.. (I think)
They do not often write 'T is.
In Dutch it should be
't Is..
't Ging er ons over..

Does it make the txt less understood? No, perhaps not, but is is not right nonetheless.
Diminutives are a major problem in txt database.
A great many words that should come out split, come out joined together.
So one adds those in OCR replace fix, and every so often it won't work because the ruling for diminutives overrules your fixing.

What I am saying is, MOST, if not all, software programs for grammatical and spelling control have a tough nut to crack when they deal with Dutch texts.
So?
It is the human end that has to do the final check, and that depends on how much time and 'gusto' that human has.
(Goesting, from Spanish, imported in the times of Alva?)

I think there is one rule that surely overrides any other.
IF...
If the subtitle translation 'sounds' wrong to your ears, there is something wrong.
If it reads like you never hear anybody speak or saw written, there is something wrong.
So one checks that part.
And if one is interested enough in fixing something instead of just "mouthing" a remark like "oi Linda, ya really hear that? And that ain't what was wrote there... rewind the film some, and...)
Well, if one is truly interested one finds a way to fix it instead of making useless and 'unheard/ignored' comments in 'your space'.

I figured out that once you get interested enough, one can help the community that helped you to subtitles.
I also find it rewarding.
By doing something right... like?
Fixing errors in subtitles of films I bought and found lacking because of hack jobs, or getting subtitles to dvdees that had no dutch subtitle on it.. and fixing those to synch with the rip I have to make of it to make a sub go with it...
It truly works both ways.

And yes, there are rules in the program that tell me lines are too long, and so on.
But, once again, Dutch and Flemish seem to have a long list of long words and even longer "samengestelde" woorden that just don't do well on screen, for some reason or another.

Hmmm.
I wondered wether there are people sharing their exeption and replace OCRfix lists..
That would be interesting to have.
BUT...
No program can, as yet, truly replace the human with gusto. Despite its dedicated writers trying to have it understand rules.
<for dutch>
Kind regards

kerremelk
Posts: 82
Joined: Sun Jan 12, 2014 2:47 pm

Re: guidelines for subs

Sat Feb 21, 2015 12:23 am

Small Brow...
the thoughtful grasshopper...

Let's put all fun aside.
I really think that rule based length goes..
with familiarity of words, dialectic use, and such.

In translation, a helluvalot won't just translate,
like sunufavbitch.

Somehow emphasised 'italicised' , they come output like garbage words.

I don't get it.
Even mark & sonépouse (and other translators we know are friendly to open source..) get OCR"d wrong.

Them translations were for Dutch.
OCR from DVD their work shows on, often looks 'stolen' and poorly applied.
I mean, I sometimes find better (better translated, cleaner) txt and timings on Open sub org in later uploads, than what i find on cheap DVD one gets from retailers like (( fill yar p1ck.. z22man, ald1, 1dl1))

I also realise that one has to be open to experimental work, and try out the settings that are 'there to change' in the software one uses.

FOR instance.
Just recently I tried to use "custom color background" in subtitle edit while I scanned an almost inelligble 'red/black/white" old file I had scanned.
It was an IDX/sub from retail DVD.

To my amazement, and great pleasure, it made the dumped output txt from like 80pct (981 from 1143) unreadable, to only 112 lines to correct/unknown words to look at.

So?

I am telling you that even people from a different profession, can learn how to play with a team willing to teach them, and can learn how to help themselves get helped to better subtitles.
After I proofread and watched the movie with that stuff I had 'by hit and miss learning' conjured up...
I thought it was a great improvement.
I uploaded it, because I knew it was not there yet.

OK, Master SmallBrother, from another topic you answered to I realised that resynch and checks and translation overhaul -verbeteringskes- have value.
Since then, I have put up a few I thought were just improvements to what OSORG had to offer (on files I can play.)

But That, and not that exactly, is what we also need.
Not just people, but people willing to learn how to fix what was provided for free.

And I really have the greatest admiration for people doing full translations.
I did only a few, so far, and doing them I begat de bedingusses.
(in dutch, het beding. de verschillen. het overleg nodig om 1 betekenis van wat er gezegd werd te laten prevaleren over de woordspeling die ook geimpliceerd werd.)

erm... the realisation that translating for film is not just doing it almost right.

Hey, does it show I like what you do?
I like what I get, and I like to fix what I do not like.
That"s what one can do here, and I really like THAT.

The fun part is, what you did will get used, somehow.
Even duff error chockfull a block error per minute stuff (like 64 minutes with timing overlaps due to amateuristic film conversions for a 98 minute film... CAN be useful once it gets treated for a good release of same.)

I might get started to write on how to help do things in only a few, the select few found to be truly gratis, software proggies.
Not on all I have tried and dispensed with..
And lord, there are many of those.
Kind regards, Jaak.

User avatar
hector
Posts: 370
Joined: Wed Jan 01, 2014 12:27 pm
Location: Spain

Re: guidelines for subs

Mon May 18, 2015 11:26 am

I use dots at phrases that go over several items at the end of the first item and at the beginning of the next, because I have noticed that you read items with dots fluently, because the dots point out that the statement continues.
In these cases I do not use commas, just the dots.
Personally I don't like this approach. I find it annoying. I think punctuation is enough to separate sentences and you don't need to join them together. You don't need to say "hey, this continues" because you know that it continues until you find the final ".". Besides, these dots occupy a valuable space. Don't you think?

User avatar
arcchancellor
Moderator
Posts: 202
Joined: Sat Apr 03, 2010 12:56 pm
Location: Ankh-Morpork

Re: guidelines for subs

Tue May 19, 2015 7:37 am

So far I have not yet decided if I proceed so further.
Feedback from users is about 50:50. Some like it, some don't.
But I have no problems with the length i.e. the valuable space.
"I don't believe in God. I just believe in Billy Wilder" - Fernando Trueba

User avatar
SmallBrother
Site Admin
Posts: 3724
Joined: Sun Mar 04, 2012 12:59 pm
Location: Somewhere on this globe

Re: guidelines for subs

Tue May 19, 2015 8:02 am

I like the three dots at the end to show the sentence continues. Theoretically not necessary, but it is more clear, more explicit.
The three dots at the beginning of the following part are not necessary though (clarity was already made right before).

And three dots in a proportional font is the same space as one "m". Well, almost.
Nowadays a VPN is a must for everyone. A VPN allows you safe surfing and protects you against spying governments and companies.
I advise AirVPN - from € 2,75 per month. Click the below banner for more info.


Image

Return to “General talk”

Who is online

Users browsing this forum: No registered users and 50 guests