Participatory Culture Foundation

Yes, I also have the copy-paste problem. There would be a workaround *, but it'd be darned boring so let's hope it will get fixed.
And I agree with Verone re the new subtitle line length. On one video I subbed with rather long subs, the last words get cut off with the new "4 short lines" format.

* Update: Actually there is a non boring workaround: http://subtitle-horse.com/: you can create a subtitling page from the original video (not the Amara page) and then, in File -> Import, there is an import as transcript option by which you can upload a .txt file. You can then do the sync there, then export as .srt for upload to Amara.
If you have heaps of subs, just sync them very roughly: you can then fix the sync'ing in Amara.

Thanks for your replies, and in particular for this one, Darren. I'm looking forward to the possibility to use .txt transcripts again. However, for me as Mac user, having to upload them will mean having to create a file with LibreOffice, which correctly encodes in UTF-8, instead of just inserting empty lines in a TextEdit file, then copy-pasting, which doesn't do UTF-8 encoding correctly when you save as .txt. And TextEdit may be a rotten software for producing files, but it's faster than LibreOffice for opening one. Dunno about Apple Pages or MS Notes or Word.

Re sub length: the 32-35 limit is only a standard for DVDs, where the sub wraps around if it is longer, and for TV, because a TV screen is wider than an online player, so a longer line might make "catching" it in one go more difficult. Not for online videos: neither other captioning platforms, nor video hosting platforms supporting CC subs implement it.
Coupled with the fact that Amara also shows as ghost subs the ones already on original YT videos, Amara wrapping around subs after 32-35 characters produces odd results. See the attached screenshot of Niños Incómodos as embedded from Amara in Margaret Warner's The Most Important Presidential Race You Haven't Heard About  on PBS.org:
The 2-line white subs are the Spanish, Mexican Amara ones with the Amara-imposed line-wrap, the 1-line ghostly gray one is the YT one, in French because YT detected that my browser speaks French, and was produced by upload to YT of the srt file of the French Amara subs where as you say, the arbitrary Amara line-wrap didn't get transfered.
Actually, this line-wrapping misunderstanding of the 32-35 character "standard" produces the exact opposite of what some users asked for in the old help forum. They asked for the possibility to insert line-breaks where they decide themselves to fit the 32-35 character length when it's needed,e.g. LEST longer subs wrap around when re-used in a DVD, or because they need 2 lines to do different things in each.
There is a workaround: see Margarita Shamraeva's reply to one of those  users on December 8, 2011:

Regarding your question, at this time subtitling dialog does not support the use of line break symbols in the middle of a subtitle block. However, you can import (upload) subtitles with line breaks from a file in SRT format. Hence, the workaround - if line breaks inside subtitle blocks are absolutely necessary, you can:
1. Create and sync subtitles with the use of UniversalSubtitles.org.
2. Download them to your computer as a file in SRT format.
3. Edit this file in a text editor of your choice, inserting line breaks as desired (maximum 3 lines per block).
4. Save the file and upload it to universalsubtitles.org.

But she added:

One caveat: once this is done, you will no longer be able to edit your subtitles on-site, with the use of the subtitling dialog - otherwise, the formatting will be lost.

And that's one big caveat, considering that Universal Subtitles / Amara is a collaborative platform where anyone can come up after you think you've finished your subs and edit them, e.g. to correct a typo you've made.
In fact, the original YouTube video, Jonathan Coulton - First of May - ASL Song has 2-line subs created by linebreaks: 1st transcribing the English lyrics, 2nd rendering the ASL in block caps. When I streamed it to Amara, the original subs got streamed too. I just added something in the video description, without touching the subs themselves, but this still removed the line breaks. But at first, at least there were 1-line Amara subs with the difference indicated by the block caps. With the recent wrap-around, there are sometimes 3-line subs, with the lines cut at random (see attached screen capture).
So what users want is the implementation of the possibility to stably  insert line-breaks themselves via the Amara subtitling widget, should they need to,  because they are preparing them for a DVD or because they need to do different things in each line, as in the ASL version of Coulton's song, not the present  Amara mimicking of DVD software linewrap.
So, could Amara developpers drop this mimicking and offer us the possibility to make multiline subs with the lines separated by linebreaks where WE decide?

Thanks for the .txt file suggestion, Verone. But do the 2-line subs remain such if you edit their content (not just add time codes to them) with the Amara widget?
Because editing the content  of 2-line subs with the Amara widget is what Maragarita Shamraeve warned about when she indicated the same trick with an .srt file (see the quotation in my former post). and as she works as software tester, "of PCF products, mostly Amara and MiroCommunity" (see pculture.org/pcf/about), her replies in the old help forum have always been very informed, clear and accurate.

Re clicking CC to make them ghost subs disappear: sure. and you can also drag them outside the player, at least with FF, to make them disappear. But once you embed an Amara player in something like pbs.org, how man pbs.org users know these tricks? Even in captioning advocacy projects, often people can't tell the difference between open captions and closed captions. Let alone what you can do with CC subs - and let alone the general public.

Thanks, Verone.
Re:

Secondly if every contributor is complaining today about the new standard because we can't work properly, tomorrow it gonna be all the viewers complaining about the new standard if it becoming public (150 000viewers/month). We CAN'T read the subtitles properly this way.

I'm not sure how many viewers PBS NewsHour videos get, but see the attached video screenshot of Watch Chen Guangcheng's Phone Call to Congress, Asking to Come to U.S, at 5:41, as presently on Amara: the Amara version is also embedded in the NewsHour site (as all other NewsHour videos are so far)  in Chen Guangcheng Asks Congress Via Phone to Come to U.S (May 3, 2012)

I've dragged the present Amara subs above the YT ones so that both can be read more clearly in the screenshot, but a) few users know you can do that; b) you can only do it  with Firefox anyway, apparently.

The top version of the sub is the one NewsHour users now see after the short line ukase, with 11 words missing. The YT bottom version is the one they used to also see on the NewsHour site before, with all the words.

I happened to remember that video because I did one of the revisions of the English subs. But there must be heaps of other instances in the NewsHour videos where long subs have got similarly mangled by the new Amara short-line ukase. And the PBS NewsHour team has so far subtitled 83 videos, each in several languages, with each set of subs potentially being thusly mangled by this short-line ukase. So what are the options?

1. Team members checking each single set of subs to see if a sub has been mangled? No way: subtitling new videos is enough work, especially with the heavy complications due to Amara software slapping draft status or open tasks on subs since June 5. (OK, Amara people are working on that, but why don't they concentrate on it instead of introducing new dubious features?)
2. Amara people doing as in 1, and very fast. But then they should do it for all existing Amara subs, otherwise it would be undemocratic
3. PBS Newshour, but also all other people whose subs potentially got mangled, deciding that Amara is just for working on subs, but that for embedding and linking, they'll use the original videos with the Amara-produced subs added - problem: some video platforms - vimeo e.g. - don't support CC subs, and when they do, often the person who uploaded the original video doesn't know how to add them, or can't be contacted easily.
4. Amara people dropping the short-line ukase as the bad idea it is, and starting to work on giving users the possibility to really respect the 32ish character length, by granting them the OPTION to insert line breaks that will stick, should they wish to. But before working on that option, Amara people should first tackle the paralyzing glitch that slaps draft status / task notices on subs and disables their editing: see 1.

More examples of how the new length limit creates havoc in Next release of the Amara software: date? testing? - comment starting with "I now agree with you, Verone,"