Dev

dev@lists.roundcube.net

1 participants
4293 discussions

Umlauts / Do we need Swiss German?
by Michael Bueker 28 Dec '06

28 Dec '06

Hi, two questions about the German translation[s]: 1. Should the Umlauts in the translation file not rather read ä instead of ä, Ü instead of Ü and so on? As I understand it, those labels get displayed without further processing, so this way, we would steer clear of any encoding issues, at least for the German labels and messages. I could post a patch for this if you think this makes sense. 2. Do we need a Swiss German translation? The only major significant difference is that there's no ß in Swiss German, but rather ss is used. But I don't think this warrants a separate translation which often lags behind the other German one and contains inconsistencies. I suggest that we either agree on a special set of differences (like this one, which is the only one I can think of) and otherwise "link" the Swiss translation to the German one - or we drop it. Cheers, ~Mik

3 4

Re: Suggestion
by Brennan Stehling 27 Dec '06

27 Dec '06

It makes a lot of sense to target the commonly troubled areas like this one. My guess is this will be an ongoing issues as mail clients and servers are always changing with new releases. It would help to collect the problematic emails somehow and queue them to be resent to another email address on request. There is already the view source option so that people could paste the source into a submission form. Changing the To header should be simple, but I do not know how to add resend those messages without messing up their headers. In a Linux/FreeBSD environment I can create a text file called message.txt and place the body of a message into it. Then call this command... cat message.txt | -s "Test Message" -F tester1(a)roundcube.net But we need a way to preserve most of the original headers so that attachments will still work when resending the message to the different address for testing. Once we do have a way to resend messages we can set up this sequence... 1) User finds problematic message 2) User copies source of message 3) User pastes message into web form to collection test messages (perhaps at www.roundcube.net/testing/submitmessage.php) 4) Tester views incoming test messages (each submission is assigned a number) 5) Tester requests a message to be sent to a test email address (perhaps at www.roundcube.net/testing/requestmessage.php) 6) Tester views the same message with same RC version to view same problem 7) Tester reviews the message to write up bug report (perhaps combining with existing bug report) Naturally the user should be warned to remove personal information in the email they do not want the testers to see. When they paste the message into the submission form they could delete out parts of the body possibly. Finally, I would set up a limited group of test/developer accounts so that the message request form will not allow sending those messages arbitrary addresses for obvious privacy concerns. tester1 -> jim.pingle(a)roundcube.net tester2 -> eric.stadtherr(a)roundcube.net tester3 -> brennan.stehling(a)roundcube.net developer1 -> thomas.bruederli(a)roundcube.net developer2 -> charles.mcnulty(a)roundcube.net These addresses can be aliases so that they can go to one of the test RC installations which we have set up either on servers provided by the SAs who have volunteered their services. If anyone has an idea on how to add these collected message back to the mail spool I would like to know how that can be done. Brennan On Sat, 23 Dec 2006 16:13:14 -0500, Jim Pingle <lists(a)pingle.org> wrote: > Eric Stadtherr wrote: >> In light of the recent discussions, I've been browsing through the Trac >> tickets trying to get a feel for the distribution of bugs (display, >> database, IMAP interface, etc.). There appear to be quite a few tickets >> that follow the pattern of "RoundCube exhibits incorrect behavior when >> displaying an e-mail with <some special characteristics>." These special >> cases range from message header contents to HTML contents to attachment >> formats. > > I noticed that as well, an a lot of them are very close in description to > the point where they could easily be the same issue, or completely > different > but unless people post sample messages, there is no easy way to be sure. > >> Instead of trying to fabricate my own e-mail messages that match these >> special cases (and possible get it wrong), what does everyone think >> about standing up a "test case" e-mail account on an IMAP server >> somewhere that people can send these "special case" messages to? The RC >> development team could then each access this IMAP server from their own >> RC installations to troubleshoot the handling of the messages. > > Elsewhere in this thread I had mentioned coming up with a lot of sample > messages in many varying formats. When you take all of the different > formats > and different clients and think about how many variations there are, the > amount of test messages could easily be very large! It would really be > nice > if every client supported "standards" in the same way. :) See my recent > ticket about HTML attachments (#1484178), three different clients I tried > formatted the same message three different ways and only one is parsed as > expected. Plus I'm sure there are client options that change how some > behave > in each of these cases as well (inline vs attached files, MIME vs plain > text, etc, etc...) > >> We'd have to keep the login credentials relatively secure, and somebody >> would have to volunteer an IMAP server. >> >> What does everyone think? > > Sounds like a good idea to me. Should there also perhaps be a web form > somewhere that would inject messages into the mailbox of said account? It > might help people who have trouble forwarding messages as attachments. > That > could be a security nightmare though. > > Alternately, ticket #1484157 could be implemented to have the ability to > forward messages as attachments directly from RoundCube. It might also be > nice to have an option that would detect whether or not a message is an > attached e-mail, and optionally detach it from the e-mail and place it in > the current mailbox. In Thunderbird, this is possible with the > "Thunderbird > Attachment Tools" extension. ( http://www.supportware.net/mozilla/#ext9 > but > their site is down at the moment.) It can pull an rfc822 message out of an > e-mail and into the current folder. Even if you can't do this in RoundCube > that extension could still come in handy for tasks like this. > > Jim -- Brennan Stehling Offwhite.net LLC brennan(a)offwhite.net -- Brennan Stehling Offwhite.net LLC brennan(a)offwhite.net -- Brennan Stehling Offwhite.net LLC brennan(a)offwhite.net

2 1

Drafts in latest SVN
by Steve Block 26 Dec '06

26 Dec '06

Although I don't use roundcube as my primary mail client, I do tend to use it at the office, which firewalls regular IMAP ports. One thing I noticed today while composing a message was that I ended up with multiple copies of said message in the drafts folder. The message took a while to put together, and I appreciate the automatic draft saving, but I also feel like subsequent saves should replace the current, rather than add to it. If not, then all of the copies should be removed when the final message is sent. Not sure if this is a bug or a 'feature', but I thought i should point it out. Thanks. -- Steve Block

5 8

Re: Webmail competition
by Tomasz Pajor 24 Dec '06

24 Dec '06

That's a very good idea. I'm looking forward in to it. Still waiting for svn access, i hope Thomas will add me soon. There are some tickets I want to close, and reorganize roadmap. I've started some, but I think we need to discuss it in a group, what we want to put to 0.1-release. -- Best regards Tom Dnia Thu, 21 Dec 2006 09:29:39 -0600 napisales[as]: > I am all for a scheduled push for contributors to meet online to work on the tickets for the next release. Perhaps we can schedule something for > January for all of us to meet online using a IM client which supports a group chat. (Skype, GTalk, etc) > > Thomas, you could walk us through your plans and each of us could volunteer to work on specific tickets. Perhaps after a few of these sessions we > will be past the next release. > > Brennan > > On Thu, 21 Dec 2006 15:17:46 +0100, Michael Bueker m.bueker(a)berlin.de> wrote: >> I couldn't have said it any better - I totally agree. I like the way how >> roundcube is developing very much, we are making slow but steady progress. >> >> If you think we need a "cleanup offensive" of the code or the ticket >> system, just call for it, maybe lay out some rules (like, which tickets to >> keep, delete or tag in which way) and I'll be happy to help out. >> >> Or a drive to write up some more/revised documentation or vamp up the wiki >> - I'm sure that if you announced a major task, there will be enough people >> willing to help out. >> >> Cheers, >> ~Mik > -- > Brennan Stehling > Offwhite.net LLC > brennan(a)offwhite.net >

8 12

Preview Pane on Safari (& other minor glitches)
by Brian Devendorf 24 Dec '06

24 Dec '06

I found that I had to tweak the CSS code for the preview pane to display properly in Safari. (This is when using the latest svn code: r432). Line: 144-151, /skins/default/mail.css /*\*/ html>body*#messagecontframe { [height: 40%; height: 54%; ]height: 100%; } /**/ I changed the value on line #148 from 40% to 54%. This adjustment was a perfect fit for the preview pane on Safari for me. I am running 10.4.8. Safari 2.0.4. Has anyone else seen this issue? According to the information in trac, the middle value only applies to Safari, so I do not expect that it would break anything else. I do most of my work in Camino, so I just noticed this little glitch today. Other minor issues I am looking into... On Safari, with preview pane, the first time I click on an email, the preview pane flickers (keeping the empty message logo). After that, everything works fine. In Camino, with preview pane or standard display, when I click Display Images on an email, it works the first time, but fails each subsequent time. This is true on an individual message basis. It always works the first time on ever message. In fact, it works the first time in preview pane, and the first time in standard view. I hope to do more research into these issues, but thought I'd check to see if anyone else had seen them first. Thanks, Brian

1 1

Suggestion
by Eric Stadtherr 23 Dec '06

23 Dec '06

In light of the recent discussions, I've been browsing through the Trac tickets trying to get a feel for the distribution of bugs (display, database, IMAP interface, etc.). There appear to be quite a few tickets that follow the pattern of "RoundCube exhibits incorrect behavior when displaying an e-mail with ." These special cases range from message header contents to HTML contents to attachment formats. Instead of trying to fabricate my own e-mail messages that match these special cases (and possible get it wrong), what does everyone think about standing up a "test case" e-mail account on an IMAP server somewhere that people can send these "special case" messages to? The RC development team could then each access this IMAP server from their own RC installations to troubleshoot the handling of the messages. We'd have to keep the login credentials relatively secure, and somebody would have to volunteer an IMAP server. What does everyone think? -- Eric Stadtherr estadtherr(a)gmail.com

3 2

HTML Cleanup for onclick/onchange/etc causes problems
by Brian Devendorf 23 Dec '06

23 Dec '06

I identified a problem in the /program/steps/mail/func.inc regexp for cleaning html code. To summarize, the cleanup code looks for the word 'on' followed by a number of non-equal characters. This should identify onchange, onclick, etc... the problem is the code fails when the word 'on' is outside of an html tag and a tag with an equal sign (eg. html link) follows it in the email. I saw the problem on order confirmation emails from Amazon.com. I created a ticket in trac that contains a patch for this regexp to verify that the word on is contained inside a tag. The patch is a unified diff, and I also attached a testcase. View the ticket here: http://trac.roundcube.net/trac.cgi/ticket/1484183 As my first post to this list, I must acknowledge what a truly fantastic product RoundCube is. Thanks, Brian

1 0

Re: Next Beta Release
by chasd 22 Dec '06

22 Dec '06

> Matt Kaatman said: > > Do we have any goals before we release the next beta? > > Maybe a feature freeze is in order to get a newer beta out? I think a release that includes the vulnerability fix - <http://trac.roundcube.net/trac.cgi/ticket/1484109> should be made, so new RoundCube users don't have to patch their fresh install. Many first time users will likely choose to download a beta release rather than an SVN snapshot that contains the fix. Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265

2 1

Hungarian language files, updated
by Szalma László 22 Dec '06

22 Dec '06

Here goes the updated Hungarian language files, please somebody commit it with the next update. http://dblaci.hu/hu.tar.gz Thanks DB

1 0

Re: #1326320
by Thomas Bruederli 22 Dec '06

22 Dec '06

Hi Pierre Please update your local copy to the latest revision (svn update) and then create the diff again. The current one removes newly added features :-( ~Thomas Pierre Lena wrote: > Here is the diff file. > > Regards. >

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Dev