Rivera Ernesto написа:
Now that we are in the middle of the project schedule and the
translation OSGi module is mostly done I will turn to the SIP part of
For this I would like to give a more precise idea of the way the project
will look at the end of the program. Many features from the past
proposal have changed or have been removed in order to have a solid and
not half-finished version 1 (upon which further development can be
cleanly done beyond the scope of SoC).
* Translated text presentation:
- Translation will be inline for v1. It is both easier to implement and
consistent with outgoing translations as we don't know (neither we can
control) the partner client's GUI.
When you say inline, you mean that you would append translations to the
text of the original message. Am I correct? If yes then I like the idea
as it is quite simple. The fact that it is not transparent to users and
that they would be aware that they (or their contact) is using
translation is also a very good thing.
- In order to distinguish translated text it could be on italics, a
different color, etc. Are those text styles available for SIP supported
Yes they are. The receive message panel in the chat window fully
- Again as SIP will communicate with other clients and multiple
protocols, it maybe wiser to just enclose with other text, ex.:
I like it very much!.
* Menu bar
- Instead of using the icons toolbar, I intend to implement an extra
menu between "Settings" and the "?" menus.
- Menu items just before the separators are informative items, as such
they will be grayed out and updated during runtime as needed.
Good. I am just thinking that the configuration dialog should be in the
general configuration form for UI consistency. You can then make the
"Options..." menu item actually open the configuration form and select
the corresponding tab.
* Translation options
- Choosing the last option of the translation menu opens this window. It
focuses more on what users want (translate text) so there it's not
a typical combo box with all available language pairs. I think it is
quite clean and minimalist GUI.
Yes it is and I like it but I think we can improve it slightly. I'd
suggest that the "Translate" menu contains several translation pairs
that the user has selected and that are, ideally, those that he uses
most often. The list would get populated from the configuration form.
The chat dialog currently allows the user to make a choice for both the
source and the destination languages and I think this is slightly
inconsistent with the way translation services work.
Most translation services define a number of pairs and let users choose
among them. However they do not always support translations from and two
all the languages in these pairs. Yahoo! Babel Fish for example has the
German to English
English to German
Greek to English
English to Greek
but there's no possibility to translate from German to Greek or vice versa.
I am therefore thinking that the configuration interface should show the
pairs as they are supported by the translation service. It could also
give the user the possibility to choose among these pairs and add them
to a list of frequently used ones. The members of this list would appear
as menu items in the "Translate" menu.
How exactly you design the configuration dialog is up to you. One way to
do it would be to display two lists to the user and give them the
possibility to move pairs from the one to the left (containing all
pairs) to the one on the right (containing only those selected by the user).
Alternately you could simply add check-boxes against all the pairs and
let users select the ones they need.
- Settings will depend on the current partner.
You mean that they would depend on the currently selected chat tab
right? Good idea though I am not certain we need this in the beginning.
I think we'd better start with a global setting. We can always add the
chat-dependent behaviour if we think it's necessary and if we have the time.
Please feel free to comment and give feedback on what you think version
1 should be.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com