This is Firefox-specific and cannot be changed. https://github.com/roundcube/roundcubemail/issues/5125

I guess on iOS the field have to be defined as <input type="email"> to get "@" in default keyboard. However, you can configure Roundcube to allow usernames that aren't email addresses, so it's not as simple as switching type=text to type=email.

Doesn't this depend on your phone? I have my standard S7 keyboard and there I can find the @ on its usual spot

@Elias96
Isn't the main point here that an empty screen opens? Or is the main problem that you want to point out the Create-button? Because if it it's really only about the Create-button, then you would have to demand - for reasons of consistency - to change it (making it bigger, for example) for all situations in the programs where the Create-button is shown (e.g. also for creating new contacts, new folders, etc.) ... Is that what you want? If yes, we would have to change the ticket description, I guess...

Ah, sorry, I should have read well...! :D Thanks again!

In T3299#49021, @Moritz wrote:

Probably not necessary anymore but I have no problem on galaxy s6 as well.

@Moritz Actually I would say very necessary because your comment makes clear that this is not only an iOS problem (as I thought after Alem's comment)!!

Probably not necessary anymore but I have no problem on galaxy s6 as well.

Thank you, I'll change the ticket description then!

@bohlender
We (Viktoria, Catherine, Annika, Moritz, and Laura) have already discussed this issue in the seminar on Friday, so I think it doesn't need any "validation" from other seminar participants here. The question is, though, whether this is a bug that can be fixed from your side (see Note in the ticket description)...

Works on my phone (Oneplus 3t, Android 8.0). Seems to be an iOS only problem

@Moritz
Could you maybe validate whether this applies to Android as well?

Mir persönlich geht es so, wenn ich eine Rechnung o.ä. suche (PayPal etc.)

Tatsächlich reicht es mMn nur, wenn man es bereits weiss. Ich musste mir dessen auch erst bewusst werden.

Die Übersetzung von den Funktionen ist nicht korrekt. Schnellantworten heist z.B. "responses" in der englischen Version.
Bitte die anderen auch noch überprüfen.

Sehen das die anderen genau so?
Reicht die "Successfully saved" Nachricht nicht?

@David__
Im Grunde hast du recht: jeder geht erst mal davon aus, dass gesendete Emails im Ordner "Gesendet" gespeichert werden. Wäre evtl auch möglich, das Ganze über die Settings zu ändern (also wenn man will, dass Emails woanders landen)...?
Was eine separate "nach dem Versenden speichern in"-Funktion halt ermöglichen würde, ist, dass nicht alle gesendeten Emails immer im gleichen Ordner landen, sondern dass man halt jeweils einstellen könnte, dass z.B. die an Arbeitskollegen versendeten Emails in "Firmenkorrespondenz" landen usw. Momentan müsste man diese Emails halt praktisch nach dem Versenden als batch aus dem Gesendet-Ordner in einen neu erstellten Ordner verschieben...

Mir geht's ähnlich wie Moritz: Ich zweifle auch den relevanten Bedarf der "Nach dem Versenden speichern in..."-Funktion an. Ich fände es intuitiver, wenn verschickte Mails zunächst grundsätzlich im "Gesendet"-Ordner landen. Sollte es bei einzelnen Nachrichten nötig sein, die woanders zu speichern, kann man dann immer noch über eben diesen Ordnern drauf zugreifen. Erwartungsgemäß wird das aber nicht sonderlich häufig der Fall sein, oder gibts es da andere Erwartungen zu den Nutzungsformen?
Vorschlag also: "Nach dem Versenden speichern in..."-Funktion streichen.

@EbruKaya
Ja, an sich schon, aber dafür müssten wir uns erst mal einigen, was genau wir denn jetzt als Lösung hernehmen wollen... Wäre vielleicht gut, genau das morgen nochmal kurz mit dem Michael (und den anderen Personen, die jetzt hier in der Diskussion involviert waren) zu besprechen und es dann zu übersetzen.

Punkt drei gefällt mir sehr gut! Soll das hier nicht übersetzt werden?

Technicly we could do the same we do with special mail folders yes, but...

1. Kolab allows subfolders and we often have "Contacts > Personal Contacts" folders too. Translating also this one would be problematic, as well as translating only it's parent.
2. Roundcube/Kolab allows global (ldap) addressbook, it's name is also not localizable. So, again inconsistency.
3. User can rename folders, so we'd need some more code to handle that properly for addressbooks and others (and e.g. implement use of the "show original folder names" preference).

So, I think that's why we do not localize the default contacts folder. Too much effort, but of course you can open a ticket to re-consider.

@machniak
We are translating special mail folders like "Inbox" and "Sent".
Could we do the something similar for "Contacts" and "Calendar" ?
Otherwise we have incomplete localization in our Kolab/Roundcube installation.

Kolab addressbooks are just folders, so users can rename them by themselves. It's also possible to have the folders in German by default on your own Kolab installation. We however do not have localization-dependent name for the "Contacts" folder.

Ich seh das auch so, wie Nadine; für Konsistenz von Symbolen und Beschreibungen fände ich es sinnvoll, das gleiche Symbol für den Button"Compose E-Mail" und den Unterordner "Composing E-Mail" in den Einstellungen zu verwenden:

@machniak
can we translate folder / addressbook names?

Ich machs mal zu. Bei Bedarf können wir es auch wieder auf machen.

Das Blatt mit dem Knick ist eigentlich für Dokumente reserviert.

I use the Samsung Galaxy S7

I could reproduce it by trying it a few times (the problem didn't occur every time). My phone is a Samsung Galaxy S5 Mini with Android as OS.

Dann müssen wir ein symbol vorschlagen, dass besser geeignet ist.

@bohlender ich finde dass composing durchaus passt, nur dann das Symbol eben das falsche ist.
So war das auch von @David__ gemeint so wie ich das verstanden habe

Ich denke, dieses Ticket ist fertig @bohlender

Von mir aus ja.

In T2705#48679, @NG wrote:

Dann ist die Funktion mit 'composing' aber falsch benannt oder?

Die Probleme, die in diesem Ticket beschrieben sind, haben wir ja bereits in mehrere Tickets aufgespalten und übersetzt. Können wir dieses dann schließen, @bohlender bzw. @David__ ?

Dann ist die Funktion mit 'composing' aber falsch benannt oder?

@NG ?

Ja. Alles super.

@bohlender
ready?

Ja vor allem geht es darum, die Lupe klickbar zu machen - das mit Enter und dem Drop-down-Menü kann ja sonst so bleiben

@Laura
Ja, im Grunde genommen geht es ja dann nur darum, die Lupe klickbar zu machen und damit die Suche zu starten, oder?

@Moritz
Und ja, ich würd sagen, du kannst das Ticket entsprechend ändern ;)

Also dann sagen wir, wir machen die Lupe grün und ermöglichen aber trotzdem auch noch, das Ganze auch über Enter machen zu können?

@Viktoria Dann Ändere ich das entsprechend in der Taskbeschreibung?

Sehe ich genauso!

In T2987#43886, @Laura wrote:

Vorschlag:
Button mit Lupensymbol, der ohnehin links vorhanden ist (siehe obige Screenshots), grün und anklickbar machen, sodass erkennbar ist, dass zum Starten der Suche darauf geklickt werden kann.

@bohlender Does this simply count es bug for iOs and is therefore ready for upstream?

@EbruKaya ?

Ist das jetzt ein Problem oder nicht?