Hi folks,
one of my customers requested a feature that is available in thunderbird.
It's called "send as new mail" there. I figured out that it should be easy
to add to roundcube. I used the forward command as a template and tried to
add a new command on my own. But it's not working as intended. The command
button is shown but it's disabled in all cases. I expected that it is
available when the forward command is available, but it's not. I've changed
the files program/steps/mail/compose.inc, program/js/apps.js,
skins/default/templates/mail.html and skins/default/templates/message.html.
I can provide the diffs to version 0.2-beta if needed. Does anyone has an
idea where to change the code in order to get this extra function working?
Regards
Christian
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hey all,
I ran into a problem in the way RoundCube handles mail messages with
"Date:" headers that aren't 100% compliant with RFC 2822's date format.
The header in question is:
Date: Tue, 21 Oct 2008 00:13:54 0600
Notice that the time zone offset specifier is missing the "+/-" prefix.
Thunderbird seems to drop the zone offset in this case and assume it's a
local date. RoundCube, on the other hand, passes it into PHP's handy
"strtotime" function which interprets 0600 as the year. This leads at
the very least to display problems (in the message list and the message
display), and worst case to invalid dates in the database if caching is
enabled.
I'd like to make RoundCube a little more tolerant, so I was wondering
what everyone else thought about possible solutions. The options I'm
considering are:
1. Parse the date using a fixed format string (e.g. "D, d M Y H:i:s
O") and one of PHP's other date functions. This would prevent
misinterpretation but might be even less tolerant.
2. Analyze the string before passing to strtotime() to identify and
work around known issues (of which there would be exactly one at
this point). This is a single special case kind of solution, but
strtotime might be reliable enough that this is the only case
we'll hit.
3. Find a 3rd party RFC2822-compliant PHP date parser library.
What do you all think?
--
*Eric Stadtherr*
estadtherr(a)gmail.com <mailto:estadtherr@gmail.com>
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hello,
It has been suggested to use .po files for translation. This may be a
viable path, but it may introduce unneeded complexity.
My real concern is about semantic changes in translatable strings. For
example, if en_US 'foo' has "Do bar" as a string and then later changed
to "Do baz", all other translations are left unchanged, because the
online translator does not detect the change in meaning.
To combat this, an original en_US string may be added as a comment after
the translated string.
Examle.
in en_US:
$labels['changecolor']='Change color';
in en_GB:
$labels['changecolor']='Change colour';//Change color
After 'Change color' is changed to 'Change text color', translator
should offer to revise the translation in all locale files because the
comment in the locale file does not match the current en_US string.
--
Dennis
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hello,
I have updated the Russian translation. There are some refinements.
--
Dennis
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/yW/JEtR4sh6/ru_RU.patch
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
When editing contacts, some invalid characters are not stripped or
handled in some way. They make it all the way to the sql statement
before things trip up. (Using a prepare statement thankfully prevents
injecting a second statement. More details in:
http://trac.roundcube.net/ticket/1485504)
I can work on a patch, but I'd appreciate some guidance first:
Should the backend explicitly validate the input against a regular
expression?
What is valid/invalid?
How should the interface report bad characters and/or failed contact
saves to the user?
Thanks,
Ziba
Webmaster Team
University of Michigan
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hello,
filled in the blanks in Finnish/Suomi labels.inc and messages.inc
Please find them in attachment.
T: Veljo Velling - W -
--- 8< --- detachments --- 8< ---
The following attachments have been detached and are available for viewing.
http://detached.gigo.com/rc/1N/OmS1pV1I/rc-finland-labels-me.zip
Only click these links if you trust the sender, as well as this message.
--- 8< --- detachments --- 8< ---
_______________________________________________
List info: http://lists.roundcube.net/dev/
Just found another one - I'm not attaching a whole new file, since it's
only a single entry:
foldermoving - Moving folder... - Перемещение папки...
Cheers,
HC
--
Hans Christian Saustrup
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hi there! One entry was missing from the Russian labels.inc fil:
skipdeleted - Do not show deleted messages - Не показывать
удаленные сообщения
Cheers,
HC
--
Hans Christian Saustrup
_______________________________________________
List info: http://lists.roundcube.net/dev/
Hello guys,
When I tried to to do a spellcheck in HTML, I got a enconding problem if it has international chars, like á ç ã and so.
After some search I had to change the file: program/js/tiny_mce/plugins/spellchecker/classes/GoogleSpell.php
And then remove the utf8_encode line from the function getSuggestions().
That's probably because the encoding is already done or incompatible. I tried Firefox 3 and IE7 on Windows Vista.
Hope it helps someone.
Jonathan Araújo
Administrador de Infra-estrutura de TI
Gerência de TI - INDG S.A.
--------------------------------------------------------------------------------
Este documento pode incluir informação confidencial e de propriedade restrita do Instituto de Desenvolvimento Gerencial-INDG e apenas pode ser lido por aquele(s) a quem sido endereçado. Se você recebeu esta mensagem de e-mail indevidamente, por favor avise-nos imediatamente. Quaisquer opiniões ou informações contidas neste e-mail pertencem ao seu remetente e não necessariamente coincidem com as do Instituto de Desenvolvimento Gerencial-INDG. Este documento não pode ser reproduzido, copiado, distribuído, publicado ou modificado por terceiros, sem a prévia autorização por escrito do Instituto de Desenvolvimento Gerencial-INDG.
This document may include proprietary and confidential information of Instituto de Desenvolvimento Gerencial-INDG, and may only be read by those persons to whom it is addressed. If you have received this e-mail message in error, please notify us immediately. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Instituto de Desenvolvimento Gerencial - INDG. This document may not be reproduced, copied, distributed, published, modified or furnished to third parties, without the prior written consent of Instituto de Desenvolvimento Gerencial-INDG.
--------------------------------------------------------------------------------
_______________________________________________
List info: http://lists.roundcube.net/dev/
hi there,
There are some changes I find appropriate to do regarding the classes, which
are stored in the include directory.
The motivation is to improve the modularization _and_ to avoid flooding the
include directory with dozens of small files.
I've got features which use LDAP (yet structurally extensible to additional
mechanisms) and I need a more basic and standard LDAP class for that.
1. - I'm currently splitting the rcube_ldap class in two:
1.1 One specific to the addressbook feature (with the very same behavior as
before), with inheritance from the classe described in 1.2.
1.2 - Another one being a superclass, for generic ldap access.
>From what I could understand on the philosophy of the classes used in RC,
although we may have several classes in the same file, only one is supposed
to be externally accessible (and it seems that the filename itself is used to
determine which one).
Once we start modularizing things (like allowing a different mechanism for
external addressbooks, instead of only LDAP as currently it is), if we follow
this logic we may end with too many files.
2. Now about what I am proposing.
I'll give an example which, hopefully, will clarify what I have in mind:
2.1 - To create a new rcube_ldap.php file with a generic LDAP class only (yes,
addressbook code would have to the moved to another place, or we could call
the former rcube_ldap_generic.php to simplify the transition).
2.2 - A rcube_XYZ.php file providing a specific feature (addressbook, user
identity etc). In that same file there are additional classes providing
services according the mechanism chosen (LDAP etc). This file would have the
XYZ-specific code when dealing with LDAP (through the generic LDAP class) and
any other mechanism which could be added in the future.
It _seems_ to me that the current philosophy expects the item 2.2 to be broken
in two or more pieces, from what I see no practical benefit (and it would add
lots of files once we start to support extra mechanisms).
If my understanding is incorrect on this, please someone tell me so.
Comments?
Suggestions?
--
Daniel Mealha Cabrita
Divisao de Suporte Tecnico
AINFO / Reitoria / UTFPR
http://www.utfpr.edu.br
_______________________________________________
List info: http://lists.roundcube.net/dev/