Hi, Thanks everyone for your comments. On Mon, Aug 18, 2014 at 7:51 PM, O.J. Sousa Rodrigues < [email protected]> wrote:

2.2.2++ and 2.4++ Both look very good. What about a combination of designs? When more than 3 languages then another design will be active!?

We don't usually do this, especially because with XWiki's complexity it will make it harder to test it (test every feature/display for 1,3,5,10+ entries). We try to select the most scalable solution and implement that, but dynamic/adaptive approaches are interesting as concept :) So the final solution for the separation will be 1.1 + a 2.x variation. I like 2.2.2 too. The problem with 2.4 is that Bootstrap is not supporting sub menus on dropdowns anymore (since 3.0 because on mobile phones interaction with them). So pressing that arrow will trigger a modal (just like we do for Export). That could be a bit weird. Thanks, Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, +1 for the Interface Language proposal. For Content Language I like 2.1.1 and 2.2.1, with a preference for 2.2.1, since it scales better. What I wonder is whether all users will make the distinction between the Interface Language and Content Language. Below the title we could elaborate a bit the text to provide more context from "Available/Current language(s)" to "Available/Current language(s) for this document / page". It's true though that that content languages are displayed right below the title in the 2.1 and 2.2 proposals so normally there shouldn't be confusions, but it might be interesting to test with a few users whether they can make the distinction. Thanks, Silvia

Hi 2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should change your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this comment with additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle <[email protected]> wrote:

...

Hi Cathy,

2.1.1 is the one I prefer, 2.1.2 is also good but the separation between language should be more clear, and it is less easy to see the active one. I have no fear about the scaling issue, even heavily multilingual site like those of the European Commission use such enumeration without issue. And as Guillaume said, it is really rare to have more than a few languages anyway. Other proposal implies multiple click/touch for the same purpose, which is bad IMO for content. It is also important to only display effectively available languages, but with an enum, it could be also good to have the option to also display unavailable one greyed, so language keep their location on screen.

Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only initial in the bar would be better IMO. Having also a more fancy solution, like what I have done with bluebird (see http://softec.lu), could be nice to have as well... or a easy way to customize it that way with an extension.

Thanks,

On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi devs,

We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of available languages in Flamingo) which is related to http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and page language settings)

While in Flamingo we could just make the language links look better, without changing the functionality, for the future, the separation is something we might want to tackle, that's why I've created this proposal page

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

I am interested in what you think about the variants.

Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Thanks, Guillaume

On Thu, Aug 21, 2014 at 12:00 PM, [email protected] <[email protected]> wrote:

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi

2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) :

...

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should change your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

We are discussing any default skin with Localization - Multilinguage - Yes. If you don't want to use it with localization you just don't activate the functionality. My remark was that when discussing individual functionality is easy to want to make each particular functionality pop. The real question is: are the language markers more important than the Last modified author? More important than the last modified time? Are they the same? Should language mark compete with the other action buttons in the content menu? etc. Anyway the fix for these problems is a 'standard'. In enumeration mode (2.1.x) the language markers were links and displayed accordingly (2.1.2), in select mode (2.2.x) they have a dropdown so they could be displayed as buttons (2.2.1). Thanks, Caty

Thanks -Vincent

...

...

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this comment with additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote:

...

Hi Cathy,

2.1.1 is the one I prefer, 2.1.2 is also good but the separation

between

...

...

language should be more clear, and it is less easy to see the active one. I have no fear about the scaling issue, even heavily multilingual site like those of the European Commission use such enumeration without issue. And as Guillaume said, it is really rare to have more than a few languages anyway. Other proposal implies multiple click/touch for the same purpose, which is bad IMO for content. It is also important to only display effectively available languages, but with an enum, it could be also good to have the option to also display unavailable one greyed, so language keep their location on screen.

Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only initial in the bar would be better IMO. Having also a more fancy solution, like what I have done with bluebird (see http://softec.lu), could be nice to have as well... or a easy way to customize it that way with an extension.

Thanks,

On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi devs,

We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of available languages in Flamingo) which is related to http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and page language settings)

While in Flamingo we could just make the language links look better, without changing the functionality, for the future, the separation is something we might want to tackle, that's why I've created this proposal page

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

I am interested in what you think about the variants.

Thanks, Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Thu, Aug 21, 2014 at 11:55 AM, Jean SIMARD <[email protected]> wrote:

Something else about the solution 2.1. Is a code of 2 letters is user friendly? It maybe easy for people which are using latin characters as native ('fr' for French, 'en' for English are easy) but does Armenian people know that they must use 'hy' or Tibetan use 'bo'?

It's really a question, maybe they are and my remark is off topic.

It is common to use those abbreviation, see http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2014_247_R_0001 for examples, of course Brazilian Portuguese will need a bit more that 2 letters, we should not forget it. That said, we could also provide some hints on mouse over. It is not perfect, since touch device does not benefit it, but when you do not know, you can also just try and you will quickly learn.

On Thu, Aug 21, 2014 at 12:10:32PM +0300, Ecaterina Moraru (Valica) wrote:

...

On Thu, Aug 21, 2014 at 12:00 PM, [email protected] <[email protected]

wrote:

...

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi

2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) :

...

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should

change

...

...

...

your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

We are discussing any default skin with Localization - Multilinguage - Yes. If you don't want to use it with localization you just don't activate the functionality.

My remark was that when discussing individual functionality is easy to want to make each particular functionality pop. The real question is: are the language markers more important than the Last modified author? More important than the last modified time? Are they the same? Should language mark compete with the other action buttons in the content menu? etc.

Anyway the fix for these problems is a 'standard'. In enumeration mode (2.1.x) the language markers were links and displayed accordingly (2.1.2), in select mode (2.2.x) they have a dropdown so they could be displayed as buttons (2.2.1).

Thanks, Caty

...

Thanks -Vincent

...

...

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this comment with additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote:

...

Hi Cathy,

2.1.1 is the one I prefer, 2.1.2 is also good but the separation

between

...

...

language should be more clear, and it is less easy to see the active one. I have no fear about the scaling issue, even heavily multilingual site like those of the European Commission use such enumeration without issue. And as Guillaume said, it is really rare to have more than a few languages anyway. Other proposal implies multiple click/touch for the same purpose, which is bad IMO for content. It is also important to only display effectively available languages, but with an enum, it could be also good to have the option to also display unavailable one greyed, so language keep their location on screen.

Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only initial in the bar would be better IMO. Having also a more fancy solution, like what I have done with bluebird (see http://softec.lu), could be nice to have as well... or a easy way to customize it that way with an extension.

Thanks,

On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

> Hi devs, > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of > available languages in Flamingo) which is related to > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and > page language settings) > > While in Flamingo we could just make the language links look better, > without changing the functionality, for the future, the separation is > something we might want to tackle, that's why I've created this proposal > page > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

> > I am interested in what you think about the variants. > > Thanks, > Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jean SIMARD <[email protected]> _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

Hello, I'm +1 for this proposal. I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1. Thanks, Manuel On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

2014-08-21 11:00 GMT+02:00 [email protected] <[email protected]>:

...

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi

2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) :

...

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should

change

...

...

...

your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

To me Flamingo can be used for a public wiki (without the app bar), which has not the same meaning as "public website" which is not necessary a "wiki" (see: http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ).

...

Thanks -Vincent

...

...

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this comment with additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote:

...

Hi Cathy,

2.1.1 is the one I prefer, 2.1.2 is also good but the separation

between

...

...

language should be more clear, and it is less easy to see the active one. I have no fear about the scaling issue, even heavily multilingual site like those of the European Commission use such enumeration without issue. And as Guillaume said, it is really rare to have more than a few languages anyway. Other proposal implies multiple click/touch for the same purpose, which is bad IMO for content. It is also important to only display effectively available languages, but with an enum, it could be also good to have the option to also display unavailable one greyed, so language keep their location on screen.

Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only initial in the bar would be better IMO. Having also a more fancy solution, like what I have done with bluebird (see http://softec.lu), could be nice to have as well... or a easy way to customize it that way with an extension.

Thanks,

On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi devs,

We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of available languages in Flamingo) which is related to http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and page language settings)

While in Flamingo we could just make the language links look better, without changing the functionality, for the future, the separation is something we might want to tackle, that's why I've created this proposal page

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

...

I am interested in what you think about the variants.

Thanks, Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On 23 Sep 2014 at 16:44:39, Ecaterina Moraru (Valica) ([email protected](mailto:[email protected])) wrote:

Hi,

These preferences were so hard to calculate since people didn't used clean +/-0/1 voted or voted positively on multiple entries, so if I misunderstood your vote please let me know.

Sorry Caty but not VOTE was started (which is why I didn’t vote). Personally I don’t like 2.2.x too much as I mentioned in the jira issue http://jira.xwiki.org/browse/XWIKI-10745 “ I don't like 2.2.1 too much on my side because it adds an extra line in the UI and thus makes it more cluttered and gives less room from the content " But let’s say if there was a vote I’d vote +0 FTM since I don’t have the time right now to review all proposals or make new proposals. At least I hope it appears only when the wiki is multilingual :) Thanks  -Vincent

Reminder: Proposal available at http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

__Short version__

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2.

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

__Long version__

Some conclusions:

* 2.1: (-0 Jean) (-1 Sergiu) ** 2.1.1: (+0 Jean) (+1 Denis) (+0 Silvia) (+0 Manu) ** 2.1.2: (+1 GL) (+0 Denis)

* 2.2: (+1 Jean) (+1 Sergiu) ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) ** 2.2.3: (+0 Sergiu) (+0 Andreea) (+0 Manu)

* 2.3: (-0 Jean) (+/-0 Sergiu) (+0 Andreea)

* 2.4: (+0 Jean) (+0 Sousa) (-0 Caty) (-1 Sergiu) (+0 Andreea)

So this means:

* 2.1: { '1': (-1) (+0) } { '0': (-1) (+0) } = -1 ** 2.1.1: { '1': (-0) (+1) } { '0': (-0) (+3) } = +1 ** 2.1.2: { '1': (-0) (+1) } { '0': (-0) (+1) } = +1

* 2.2: { '1': (-0) (+2) } { '0': (-0) (+0) } = +2 ** 2.2.1: { '1': (-0) (+3) } { '0': (-1) (+2) } = +3 ** 2.2.2: { '1': (-1) (+3) } { '0': (-0) (+1) } = +2 ** 2.2.3: { '1': (-0) (+0) } { '0': (-0) (+3) } = 0

* 2.3: { '1': (-0) (+0) } { '0': (-2) (+2) } = 0

* 2.4: { '1': (-1) (+0) } { '0': (-1) (+3) } = -1

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2. The votes were: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu)

Adjustments:

Since Segiu voted -1 on 2.2.2 we couldn't pick this version until the committer changes his vote, given the arguments.

Given Sergiu's arguments I want to change my vote for 2.2.2 from +1 -> +0 and give variant 2.2.1 a +1 vote. My rationale behind this change is that: * initially I preferred using links to display the language in order to be consistent with edit mode (language selection) * because of space constraints I believe is better to use a menu to display them * since it's a menu, I agree it should have the standard menu look * from an implementation point of view is easier to use the Bootstrap's menu component than to write a custom one for our case

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

Thanks, Caty

On Thu, Aug 21, 2014 at 2:31 PM, Manuel Smeria wrote:

...

Hello,

I'm +1 for this proposal.

I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1.

Thanks, Manuel

On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-08-21 11:00 GMT+02:00 [email protected] :

...

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi

2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) :

...

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should

change

...

...

...

your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

To me Flamingo can be used for a public wiki (without the app bar), which has not the same meaning as "public website" which is not necessary a "wiki" (see: http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ).

...

Thanks -Vincent

...

...

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this comment with additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote:

> Hi Cathy, > > 2.1.1 is the one I prefer, 2.1.2 is also good but the separation

between

...

> language should be more clear, and it is less easy to see the active one. I > have no fear about the scaling issue, even heavily multilingual site like > those of the European Commission use such enumeration without issue. And as > Guillaume said, it is really rare to have more than a few languages anyway. > Other proposal implies multiple click/touch for the same purpose, which is > bad IMO for content. It is also important to only display effectively > available languages, but with an enum, it could be also good to have the > option to also display unavailable one greyed, so language keep their > location on screen. > > Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only > initial in the bar would be better IMO. Having also a more fancy solution, > like what I have done with bluebird (see http://softec.lu), could be nice > to have as well... or a easy way to customize it that way with an > extension. > > Thanks, > > > > On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > > > Hi devs, > > > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of > > available languages in Flamingo) which is related to > > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and > > page language settings) > > > > While in Flamingo we could just make the language links look better, > > without changing the functionality, for the future, the separation is > > something we might want to tackle, that's why I've created this proposal > > page > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

> > > > I am interested in what you think about the variants. > > > > Thanks, > > Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi Cathy, I would like to add a remark to your conclusion which is very centric on the 2.2 solutions. The main complaints that have been said about 2.1 solution were scalability, and the fear that too much languages could clutter the interface, which is true at some point. However, GL mention the fact that it is really rare to have more than five languages. I also mention that 2.2 solution require more click to switch language. I would like to add that 2.1 is nearer to what we have actually, so 2.2 could be seen as an important change for existing users. A change that could be seen as less ergonomic. Switching between just two language with 2.2 is really boring compare to the same task with 2.1. The scalability issue should not drive alone the decision. There is also another aspect of between 2.1 and 2.2 that should be considered. With 2.2, you do not see at a glance, what are the available translations. Two use case here: a) You have to click once to discover that your expected language is not available. b) while reviewing the site for completeness, you need to click to know about available translation for each document. Believe me, I have work for a long time in multilingual environment, and unless your language usage is very casual, single click switch and direct view of available languages are far more comfortable than a menu choice. So, since this is still a proposal and not a vote, I think that it is still time to extends the proposal. Why not implementing a mix of 2.1 (for easy of use, and "back compatibility") and 2.2 (for scalability) depending on user configuration, with a default based on the number of configured languages ? It does not look that hard IMO, and could have the benefit of scalability and usability at the same time. I hope other will reconsider their views, because this is an important choice, and it could make a differentiator for XWiki. WDYT ? On Tue, Sep 23, 2014 at 4:43 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

Hi,

These preferences were so hard to calculate since people didn't used clean +/-0/1 voted or voted positively on multiple entries, so if I misunderstood your vote please let me know.

Reminder: Proposal available at

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

__Short version__

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2.

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

__Long version__

Some conclusions:

* 2.1: (-0 Jean) (-1 Sergiu) ** 2.1.1: (+0 Jean) (+1 Denis) (+0 Silvia) (+0 Manu) ** 2.1.2: (+1 GL) (+0 Denis)

* 2.2: (+1 Jean) (+1 Sergiu) ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) ** 2.2.3: (+0 Sergiu) (+0 Andreea) (+0 Manu)

* 2.3: (-0 Jean) (+/-0 Sergiu) (+0 Andreea)

* 2.4: (+0 Jean) (+0 Sousa) (-0 Caty) (-1 Sergiu) (+0 Andreea)

So this means:

* 2.1: { '1': (-1) (+0) } { '0': (-1) (+0) } = -1 ** 2.1.1: { '1': (-0) (+1) } { '0': (-0) (+3) } = +1 ** 2.1.2: { '1': (-0) (+1) } { '0': (-0) (+1) } = +1

* 2.2: { '1': (-0) (+2) } { '0': (-0) (+0) } = +2 ** 2.2.1: { '1': (-0) (+3) } { '0': (-1) (+2) } = +3 ** 2.2.2: { '1': (-1) (+3) } { '0': (-0) (+1) } = +2 ** 2.2.3: { '1': (-0) (+0) } { '0': (-0) (+3) } = 0

* 2.3: { '1': (-0) (+0) } { '0': (-2) (+2) } = 0

* 2.4: { '1': (-1) (+0) } { '0': (-1) (+3) } = -1

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2. The votes were: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu)

Adjustments:

Since Segiu voted -1 on 2.2.2 we couldn't pick this version until the committer changes his vote, given the arguments.

Given Sergiu's arguments I want to change my vote for 2.2.2 from +1 -> +0 and give variant 2.2.1 a +1 vote. My rationale behind this change is that: * initially I preferred using links to display the language in order to be consistent with edit mode (language selection) * because of space constraints I believe is better to use a menu to display them * since it's a menu, I agree it should have the standard menu look * from an implementation point of view is easier to use the Bootstrap's menu component than to write a custom one for our case

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

Thanks, Caty

On Thu, Aug 21, 2014 at 2:31 PM, Manuel Smeria <[email protected]> wrote:

...

Hello,

I'm +1 for this proposal.

I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1.

Thanks, Manuel

On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-08-21 11:00 GMT+02:00 [email protected] <[email protected]>:

...

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hi

2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) :

...

Hi,

First of all we need to decide how prominent we want this functionality to be. I would make it more transparent, since theoretically you should

change

...

...

...

your language preference just once (in the Administration, and per user) and all the pages should be displayed according to that preference. This is not something that need to be highly visible and that you would change every day.

It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

To me Flamingo can be used for a public wiki (without the app bar), which has not the same meaning as "public website" which is not necessary a "wiki" (see: http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ).

...

Thanks -Vincent

...

...

IMO it's more important to be better displayed when you want to create a new translation, than when you read one.

Regarding the flag to represent languages you can read this

comment

...

with

...

...

additional information about why we wouldn't do it like that

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

...

...

Thanks, Caty

On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote:

> Hi Cathy, > > 2.1.1 is the one I prefer, 2.1.2 is also good but the

separation between

...

> language should be more clear, and it is less easy to see the active one. I > have no fear about the scaling issue, even heavily multilingual site like > those of the European Commission use such enumeration without issue. And as > Guillaume said, it is really rare to have more than a few languages anyway. > Other proposal implies multiple click/touch for the same purpose, which is > bad IMO for content. It is also important to only display effectively > available languages, but with an enum, it could be also good to have the > option to also display unavailable one greyed, so language keep their > location on screen. > > Regarding the UI language, 1.1 is fine, but maybe a bit large. Having only > initial in the bar would be better IMO. Having also a more fancy solution, > like what I have done with bluebird (see http://softec.lu), could be nice > to have as well... or a easy way to customize it that way with an > extension. > > Thanks, > > > > On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < > [email protected]> wrote: > > > Hi devs, > > > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display of > > available languages in Flamingo) which is related to > > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language and > > page language settings) > > > > While in Flamingo we could just make the language links look better, > > without changing the functionality, for the future, the separation is > > something we might want to tackle, that's why I've created this proposal > > page > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

...

> > > > I am interested in what you think about the variants. > > > > Thanks, > > Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:

Hi,

Depends who is our main focus: normal users or content gardeners?

Is there really such a distinction on a collaborative wiki ? I do not think so ! Everyone is expected to be a contributor.

As an user of a multi-language site you just care if the site is available in your language. After you made the initial interface language selection, you wish to have the content displayed in the same language, or fallback on a 'neutral' language (while mentioning that the 'preferred' language is not available).

I do not really agree here either, but it could be a default. Personally, I use english interface but I would like to see content in french when available :)

A normal user does not care that a certain page has x translations or that the interface is in 30 languages, except when doing the initial preference. This could be set also from User Profile.

Are we talking about UI language, or content language. For UI language, I fully agree with you.

As a content gardener (content manager) I want to know what languages are missing in order to add them. But this info can be (and it is) displayed in the edit mode.

... in the edit mode, should I really need to open the editor to see a missing translation. It is even worse than 2.2 :) But, this is not my point. If you look at OSX for example, you may choose a complete list of language, in your order of preference, and the fallback should follow that list. So if you care about serving, what you called "normal user", you need the same kind of preference... ...or you may serve all users by simply better displaying what is available ! This also remove the need for differentiating normal and gardeners.

----

The 'easy' solution as you said is to make it configurable. And we kind of do this when we don't reach an agreement. IMO it's good and is bad, since the code and the testing gets split, so I hope we reach a conclusion.

You seems to forget quite quickly about our past. We use to have a list of links for years now, so we are talking about a major change for existing users.

The argument that there are not that many languages in the wild is hard to quantify, since we are missing user statistics.

While we do not have statistics, we have client, and we also have users, and I do not remember seeing big complaints about the way it works currently.

---

Another place where we could display the language information in the expanded state (2.1) could be near the Tags area or in the Document Information. I prefer the select approach (2.2) because the location is highly visible and we don't want to capture the user's attention on an information he might not need at all.

Basically, I agree with you about the importance of the information. However, where you seems to always see a cumbersome list of links, I see a short list of links most of the time. This is not a matter of not choosing, it is only to answer very exceptional cases, where scalability became an issue. To compare, do you think that a button labelled "Brazilian Portuguese" is more or less cumbersome than the list "EN | FR | PT-BR" ? Remember that we could display only available translations, and unless we do a remake of Wikipedia, most of the time, there will not be that many. What I propose, is not to don't reach a conclusion, is to provide best of both world !

That's why if you really want to put them as list of links, maybe we can change the location and present them more as metadatas.

It is not metadata, you miss my point. What I say is that switching/managing a small list of language is far better served by a list of link then a menu. IMO, this will be the most used case, and the large list will be the exception.

Thanks, Caty

On Wed, Sep 24, 2014 at 11:27 AM, Denis Gervalle <[email protected]> wrote:

...

Hi Cathy,

I would like to add a remark to your conclusion which is very centric on the 2.2 solutions.

The main complaints that have been said about 2.1 solution were scalability, and the fear that too much languages could clutter the interface, which is true at some point. However, GL mention the fact that it is really rare to have more than five languages. I also mention that 2.2 solution require more click to switch language.

I would like to add that 2.1 is nearer to what we have actually, so 2.2 could be seen as an important change for existing users. A change that could be seen as less ergonomic. Switching between just two language with 2.2 is really boring compare to the same task with 2.1.

The scalability issue should not drive alone the decision. There is also another aspect of between 2.1 and 2.2 that should be considered. With 2.2, you do not see at a glance, what are the available translations. Two use case here: a) You have to click once to discover that your expected language is not available. b) while reviewing the site for completeness, you need to click to know about available translation for each document.

Believe me, I have work for a long time in multilingual environment, and unless your language usage is very casual, single click switch and direct view of available languages are far more comfortable than a menu choice.

So, since this is still a proposal and not a vote, I think that it is still time to extends the proposal. Why not implementing a mix of 2.1 (for easy of use, and "back compatibility") and 2.2 (for scalability) depending on user configuration, with a default based on the number of configured languages ? It does not look that hard IMO, and could have the benefit of scalability and usability at the same time.

I hope other will reconsider their views, because this is an important choice, and it could make a differentiator for XWiki. WDYT ?

On Tue, Sep 23, 2014 at 4:43 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi,

These preferences were so hard to calculate since people didn't used clean +/-0/1 voted or voted positively on multiple entries, so if I misunderstood your vote please let me know.

Reminder: Proposal available at

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

__Short version__

So the majority of the participants liked version 2.2 with some

discussion

...

whether to choose variant 2.2.1 or 2.2.2.

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

__Long version__

Some conclusions:

* 2.1: (-0 Jean) (-1 Sergiu) ** 2.1.1: (+0 Jean) (+1 Denis) (+0 Silvia) (+0 Manu) ** 2.1.2: (+1 GL) (+0 Denis)

* 2.2: (+1 Jean) (+1 Sergiu) ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) ** 2.2.3: (+0 Sergiu) (+0 Andreea) (+0 Manu)

* 2.3: (-0 Jean) (+/-0 Sergiu) (+0 Andreea)

* 2.4: (+0 Jean) (+0 Sousa) (-0 Caty) (-1 Sergiu) (+0 Andreea)

So this means:

* 2.1: { '1': (-1) (+0) } { '0': (-1) (+0) } = -1 ** 2.1.1: { '1': (-0) (+1) } { '0': (-0) (+3) } = +1 ** 2.1.2: { '1': (-0) (+1) } { '0': (-0) (+1) } = +1

* 2.2: { '1': (-0) (+2) } { '0': (-0) (+0) } = +2 ** 2.2.1: { '1': (-0) (+3) } { '0': (-1) (+2) } = +3 ** 2.2.2: { '1': (-1) (+3) } { '0': (-0) (+1) } = +2 ** 2.2.3: { '1': (-0) (+0) } { '0': (-0) (+3) } = 0

* 2.3: { '1': (-0) (+0) } { '0': (-2) (+2) } = 0

* 2.4: { '1': (-1) (+0) } { '0': (-1) (+3) } = -1

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2. The votes were: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu)

Adjustments:

Since Segiu voted -1 on 2.2.2 we couldn't pick this version until the committer changes his vote, given the arguments.

Given Sergiu's arguments I want to change my vote for 2.2.2 from +1 -> +0 and give variant 2.2.1 a +1 vote. My rationale behind this change is that: * initially I preferred using links to display the language in order to be consistent with edit mode (language selection) * because of space constraints I believe is better to use a menu to display them * since it's a menu, I agree it should have the standard menu look * from an implementation point of view is easier to use the Bootstrap's menu component than to write a custom one for our case

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

Thanks, Caty

On Thu, Aug 21, 2014 at 2:31 PM, Manuel Smeria <[email protected]> wrote:

...

Hello,

I'm +1 for this proposal.

I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1.

Thanks, Manuel

On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2014-08-21 11:00 GMT+02:00 [email protected] <[email protected] :

...

On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

> Hi > > 2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) : > > > Hi, > > > > First of all we need to decide how prominent we want this functionality to > > be. > > I would make it more transparent, since theoretically you

should change

...

> > your language preference just once (in the Administration, and per user) > > and all the pages should be displayed according to that preference. This is > > not something that need to be highly visible and that you would change > > every day. > > > It's not true on a public wiki (like Wikipedia).

That’s a good point, we need to agree which skin we’re discussing. AFAIK we’re discussing Flamingo which is NOT a public web site skin. When we do a public web site skin we would need to take this into consideration indeed.

To me Flamingo can be used for a public wiki (without the app bar), which has not the same meaning as "public website" which is not necessary a "wiki" (see:

http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ).

...

...

Thanks -Vincent

> > IMO it's more important to be better displayed when you want

to

...

...

> > create a new translation, than when you read one. > > > > Regarding the flag to represent languages you can read this comment with > > additional information about why we wouldn't do it like that > > > >

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

...

...

> > > > Thanks, > > Caty > > > > > > On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote: > > > > > Hi Cathy, > > > > > > 2.1.1 is the one I prefer, 2.1.2 is also good but the separation between > > > language should be more clear, and it is less easy to see the active > > one. I > > > have no fear about the scaling issue, even heavily multilingual site like > > > those of the European Commission use such enumeration without issue. And > > as > > > Guillaume said, it is really rare to have more than a few languages > > anyway. > > > Other proposal implies multiple click/touch for the same purpose, which > > is > > > bad IMO for content. It is also important to only display effectively > > > available languages, but with an enum, it could be also good to have the > > > option to also display unavailable one greyed, so language keep their > > > location on screen. > > > > > > Regarding the UI language, 1.1 is fine, but maybe a bit large. Having > > only > > > initial in the bar would be better IMO. Having also a more fancy > > solution, > > > like what I have done with bluebird (see http://softec.lu ), could be > > nice > > > to have as well... or a easy way to customize it that way with an > > > extension. > > > > > > Thanks, > > > > > > > > > > > > On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < > > > [email protected]> wrote: > > > > > > > Hi devs, > > > > > > > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the display > > of > > > > available languages in Flamingo) which is related to > > > > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface language > > and > > > > page language settings) > > > > > > > > While in Flamingo we could just make the language links look better, > > > > without changing the functionality, for the future, the separation is > > > > something we might want to tackle, that's why I've created this > > proposal > > > > page > > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

...

> > > > > > > > I am interested in what you think about the variants. > > > > > > > > Thanks, > > > > Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

Hi Denis. Actually there is http://jira.xwiki.org/browse/XWIKI-10745 that I have committed yesterday on master. I will backport it to the 6.2.x branch today and so we will have it for 6.2.2. Thanks, 2014-10-01 0:38 GMT+02:00 Denis Gervalle <[email protected]>:

Hi,

After seeing that 6.2.1 still doesn't have any clean display for languages, please do what you want but do something about it. Now, I will fear discussing such topics, when I see the end result. (Sorry if what I say seems hard, I know you have made a huge job adapting Flamingo, and you should be congratulated for that anyway)

Thanks,

On Wed, Sep 24, 2014 at 11:53 AM, Denis Gervalle <[email protected]> wrote:

...

On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi,

Depends who is our main focus: normal users or content gardeners?

Is there really such a distinction on a collaborative wiki ? I do not think so ! Everyone is expected to be a contributor.

...

As an user of a multi-language site you just care if the site is

available

...

...

in your language. After you made the initial interface language selection, you wish to have the content displayed in the same language, or fallback on a 'neutral' language (while mentioning that the 'preferred' language is not available).

I do not really agree here either, but it could be a default. Personally, I use english interface but I would like to see content in french when available :)

...

A normal user does not care that a certain page has x translations or that the interface is in 30 languages, except when doing the initial preference. This could be set also from User Profile.

Are we talking about UI language, or content language. For UI language, I fully agree with you.

...

As a content gardener (content manager) I want to know what languages are missing in order to add them. But this info can be (and it is) displayed in the edit mode.

... in the edit mode, should I really need to open the editor to see a missing translation. It is even worse than 2.2 :)

But, this is not my point. If you look at OSX for example, you may choose a complete list of language, in your order of preference, and the fallback should follow that list. So if you care about serving, what you called "normal user", you need the same kind of preference... ...or you may serve all users by simply better displaying what is available ! This also remove the need for differentiating normal and gardeners.

...

----

The 'easy' solution as you said is to make it configurable. And we kind of do this when we don't reach an agreement. IMO it's good and is bad, since the code and the testing gets split, so I hope we reach a conclusion.

You seems to forget quite quickly about our past. We use to have a list of links for years now, so we are talking about a major change for existing users.

...

The argument that there are not that many languages in the wild is hard

to

...

quantify, since we are missing user statistics.

While we do not have statistics, we have client, and we also have users, and I do not remember seeing big complaints about the way it works currently.

...

---

Another place where we could display the language information in the expanded state (2.1) could be near the Tags area or in the Document Information. I prefer the select approach (2.2) because the location is highly

visible

...

and we don't want to capture the user's attention on an information he might not need at all.

Basically, I agree with you about the importance of the information. However, where you seems to always see a cumbersome list of links, I see a short list of links most of the time. This is not a matter of not choosing, it is only to answer very exceptional cases, where scalability became an issue. To compare, do you think that a button labelled "Brazilian Portuguese" is more or less cumbersome than the list "EN | FR | PT-BR" ? Remember that we could display only available translations, and unless we do a remake of Wikipedia, most of the time, there will not be that many. What I propose, is not to don't reach a conclusion, is to provide best of both world !

...

That's why if you really want to put them as list of links, maybe we can change the location and present them more as metadatas.

It is not metadata, you miss my point. What I say is that switching/managing a small list of language is far better served by a list of link then a menu. IMO, this will be the most used case, and the large list will be the exception.

...

Thanks, Caty

On Wed, Sep 24, 2014 at 11:27 AM, Denis Gervalle <[email protected]> wrote:

...

Hi Cathy,

I would like to add a remark to your conclusion which is very centric

on

...

...

the 2.2 solutions.

The main complaints that have been said about 2.1 solution were scalability, and the fear that too much languages could clutter the interface, which is true at some point. However, GL mention the fact that it is really rare to have more than five languages. I also mention that 2.2 solution require more click to switch language.

I would like to add that 2.1 is nearer to what we have actually, so 2.2 could be seen as an important change for existing users. A change that could be seen as less ergonomic. Switching between just two language with 2.2 is really boring compare to the same task with 2.1.

The scalability issue should not drive alone the decision. There is also another aspect of between 2.1 and 2.2 that should be considered. With 2.2, you do not see at a glance, what are the available translations. Two use case here: a) You have to click once to discover that your expected language is not available. b) while reviewing the site for completeness, you need to click to know about available translation for each document.

Believe me, I have work for a long time in multilingual environment, and unless your language usage is very casual, single click switch and direct view of available languages are far more comfortable than a menu choice.

So, since this is still a proposal and not a vote, I think that it is still time to extends the proposal. Why not implementing a mix of 2.1 (for easy of use, and "back compatibility") and 2.2 (for scalability) depending on user configuration, with a default based on the number of configured languages ? It does not look that hard IMO, and could have the benefit of scalability and usability at the same time.

I hope other will reconsider their views, because this is an important choice, and it could make a differentiator for XWiki. WDYT ?

On Tue, Sep 23, 2014 at 4:43 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi,

These preferences were so hard to calculate since people didn't used clean +/-0/1 voted or voted positively on multiple entries, so if I misunderstood your vote please let me know.

Reminder: Proposal available at

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

__Short version__

So the majority of the participants liked version 2.2 with some

discussion

...

whether to choose variant 2.2.1 or 2.2.2.

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

__Long version__

Some conclusions:

* 2.1: (-0 Jean) (-1 Sergiu) ** 2.1.1: (+0 Jean) (+1 Denis) (+0 Silvia) (+0 Manu) ** 2.1.2: (+1 GL) (+0 Denis)

* 2.2: (+1 Jean) (+1 Sergiu) ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) ** 2.2.3: (+0 Sergiu) (+0 Andreea) (+0 Manu)

* 2.3: (-0 Jean) (+/-0 Sergiu) (+0 Andreea)

* 2.4: (+0 Jean) (+0 Sousa) (-0 Caty) (-1 Sergiu) (+0 Andreea)

So this means:

* 2.1: { '1': (-1) (+0) } { '0': (-1) (+0) } = -1 ** 2.1.1: { '1': (-0) (+1) } { '0': (-0) (+3) } = +1 ** 2.1.2: { '1': (-0) (+1) } { '0': (-0) (+1) } = +1

* 2.2: { '1': (-0) (+2) } { '0': (-0) (+0) } = +2 ** 2.2.1: { '1': (-0) (+3) } { '0': (-1) (+2) } = +3 ** 2.2.2: { '1': (-1) (+3) } { '0': (-0) (+1) } = +2 ** 2.2.3: { '1': (-0) (+0) } { '0': (-0) (+3) } = 0

* 2.3: { '1': (-0) (+0) } { '0': (-2) (+2) } = 0

* 2.4: { '1': (-1) (+0) } { '0': (-1) (+3) } = -1

So the majority of the participants liked version 2.2 with some discussion whether to choose variant 2.2.1 or 2.2.2. The votes were: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu)

Adjustments:

Since Segiu voted -1 on 2.2.2 we couldn't pick this version until the committer changes his vote, given the arguments.

Given Sergiu's arguments I want to change my vote for 2.2.2 from +1 -> +0 and give variant 2.2.1 a +1 vote. My rationale behind this change is that: * initially I preferred using links to display the language in order to be consistent with edit mode (language selection) * because of space constraints I believe is better to use a menu to display them * since it's a menu, I agree it should have the standard menu look * from an implementation point of view is easier to use the Bootstrap's menu component than to write a custom one for our case

So the current votes are: ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) (+1 Caty) ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu)

** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1

If you want to change your vote or cast another vote, please reply to this message. Until then, the winning solution is 2.2.1

Thanks, Caty

On Thu, Aug 21, 2014 at 2:31 PM, Manuel Smeria <[email protected]> wrote:

...

Hello,

I'm +1 for this proposal.

I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1.

Thanks, Manuel

On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

> 2014-08-21 11:00 GMT+02:00 [email protected] < [email protected] : > > > > > > > > > > > On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( > > [email protected](mailto:[email protected])) wrote: > > > > > Hi > > > > > > 2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) : > > > > > > > Hi, > > > > > > > > First of all we need to decide how prominent we want this > > functionality to > > > > be. > > > > I would make it more transparent, since theoretically you should > change > > > > your language preference just once (in the Administration, and per > > user) > > > > and all the pages should be displayed according to that preference. > > This is > > > > not something that need to be highly visible and that you would > change > > > > every day. > > > > > > > > > It's not true on a public wiki (like Wikipedia). > > > > That’s a good point, we need to agree which skin we’re discussing. AFAIK > > we’re discussing Flamingo which is NOT a public web site skin. When we > do a > > public web site skin we would need to take this into consideration > indeed. > > > > To me Flamingo can be used for a public wiki (without the app bar), which > has not the same meaning as "public website" which is not necessary a > "wiki" (see: > http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ). > > > > > > Thanks > > -Vincent > > > > > > IMO it's more important to be better displayed when you want to > > > > create a new translation, than when you read one. > > > > > > > > Regarding the flag to represent languages you can read this comment > > with > > > > additional information about why we wouldn't do it like that > > > > > > > > > > >

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

...

> > > > > > > > Thanks, > > > > Caty > > > > > > > > > > > > On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote: > > > > > > > > > Hi Cathy, > > > > > > > > > > 2.1.1 is the one I prefer, 2.1.2 is also good but the separation > > between > > > > > language should be more clear, and it is less easy to see the > active > > > > one. I > > > > > have no fear about the scaling issue, even heavily multilingual > site > > like > > > > > those of the European Commission use such enumeration without > issue. > > And > > > > as > > > > > Guillaume said, it is really rare to have more than a few languages > > > > anyway. > > > > > Other proposal implies multiple click/touch for the same purpose, > > which > > > > is > > > > > bad IMO for content. It is also important to only display > effectively > > > > > available languages, but with an enum, it could be also good to > have > > the > > > > > option to also display unavailable one greyed, so language keep > their > > > > > location on screen. > > > > > > > > > > Regarding the UI language, 1.1 is fine, but maybe a bit large. > Having > > > > only > > > > > initial in the bar would be better IMO. Having also a more fancy > > > > solution, > > > > > like what I have done with bluebird (see http://softec.lu ), could > be > > > > nice > > > > > to have as well... or a easy way to customize it that way with an > > > > > extension. > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < > > > > > [email protected]> wrote: > > > > > > > > > > > Hi devs, > > > > > > > > > > > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve the > > display > > > > of > > > > > > available languages in Flamingo) which is related to > > > > > > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface > > language > > > > and > > > > > > page language settings) > > > > > > > > > > > > While in Flamingo we could just make the language links look > > better, > > > > > > without changing the functionality, for the future, the > separation > > is > > > > > > something we might want to tackle, that's why I've created this > > > > proposal > > > > > > page > > > > > > > > > > > > > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

> > > > > > > > > > > > I am interested in what you think about the variants. > > > > > > > > > > > > Thanks, > > > > > > Caty > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

Hi, My conclusion from this thread is that having a permanent display of the interface language is a waste of UI. In other words and IMO, the interface language should be a user preference just like "User Type" or "Editor Preferences" inside the user's profile. Funnily enough, we have the perfect location for that in the user profile's preferences and it's called the "Localization Preferences" section. The only preference in that section is currently "Timezone", but it is IMO the perfect location where we can add the new "Interface Language" preference. At this point, we have eliminated the need of such an option from the main UI. Now, regarding document language, I see(/preffer/vote for) one of the 2 options below: 1. Re-use proposal 1.1 since its current location is what regular users expect it to be on a regular website. It worked well in colibri and users are "used" to it, so there should be no transition problems and it will no longer suffer from the problems colibri had (of not being able to select the interface language) ...or... 2. Use proposal 2.2.1, though it kind of hurts my eye to *always* see that the document's language is "English", specially since it's a 3D-like button with gradient and border. IMO this should be an information that the user *should be able* to find and not one that the user *should always see*. One improvement we could have here is to *only* display the language selector when the current document's language is different from the user's interface language. This would work for "users", but "gardeners" would still have the classic options in edit mode. This solution suffers from the fact that you (as a "gardener") can not check existing translations for a document only from view mode (since the interface language matches the current document and the information is not displayed). To fix this final problem, we could, indeed, use the Information panel in the Docextra area at the bottom of the page as the situations where the users is interested by this information (no matter what type of user it is) are very few and this fix would not impose that the user has edit rights. WDYT? Thanks, Eduard On Wed, Oct 1, 2014 at 10:22 AM, Denis Gervalle <[email protected]> wrote:

Hi Guillaume,

I didn't found it just because I saw this as a bug, not an improvement. Sorry for the noise,

On Wed, Oct 1, 2014 at 9:09 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hi Denis.

Actually there is http://jira.xwiki.org/browse/XWIKI-10745 that I have committed yesterday on master. I will backport it to the 6.2.x branch today and so we will have it for 6.2.2.

Thanks,

2014-10-01 0:38 GMT+02:00 Denis Gervalle <[email protected]>:

...

Hi,

After seeing that 6.2.1 still doesn't have any clean display for languages, please do what you want but do something about it. Now, I will fear discussing such topics, when I see the end result. (Sorry if what I say seems hard, I know you have made a huge job adapting Flamingo, and you should be congratulated for that anyway)

Thanks,

On Wed, Sep 24, 2014 at 11:53 AM, Denis Gervalle <[email protected]> wrote:

...

On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi,

Depends who is our main focus: normal users or content gardeners?

Is there really such a distinction on a collaborative wiki ? I do not think so ! Everyone is expected to be a contributor.

...

As an user of a multi-language site you just care if the site is

available

...

...

in your language. After you made the initial interface language selection, you wish to have the content displayed in the same language, or fallback on a 'neutral' language (while mentioning that the 'preferred' language is not available).

I do not really agree here either, but it could be a default. Personally, I use english interface but I would like to see content in french when available :)

...

A normal user does not care that a certain page has x translations or that the interface is in 30 languages, except when doing the initial preference. This could be set also from User Profile.

Are we talking about UI language, or content language. For UI language, I fully agree with you.

...

As a content gardener (content manager) I want to know what languages are missing in order to add them. But this info can be (and it is) displayed in the edit mode.

... in the edit mode, should I really need to open the editor to see a missing translation. It is even worse than 2.2 :)

But, this is not my point. If you look at OSX for example, you may choose a complete list of language, in your order of preference, and the fallback should follow that list. So if you care about serving, what you called "normal user", you need the same kind of preference... ...or you may serve all users by simply better displaying what is available ! This also remove the need for differentiating normal and gardeners.

...

----

The 'easy' solution as you said is to make it configurable. And we kind of do this when we don't reach an agreement. IMO it's good and is bad, since the code and the testing gets split, so I hope we reach a conclusion.

You seems to forget quite quickly about our past. We use to have a list of links for years now, so we are talking about a major change for existing users.

...

The argument that there are not that many languages in the wild is

hard to

...

quantify, since we are missing user statistics.

While we do not have statistics, we have client, and we also have users, and I do not remember seeing big complaints about the way it works currently.

...

---

Another place where we could display the language information in the expanded state (2.1) could be near the Tags area or in the Document Information. I prefer the select approach (2.2) because the location is highly

visible

...

and we don't want to capture the user's attention on an information he might not need at all.

Basically, I agree with you about the importance of the information. However, where you seems to always see a cumbersome list of links, I see a short list of links most of the time. This is not a matter of not choosing, it is only to answer very exceptional cases, where scalability became an issue. To compare, do you think that a button labelled "Brazilian Portuguese" is more or less cumbersome than the list "EN | FR | PT-BR" ? Remember that we could display only available translations, and unless we do a remake of Wikipedia, most of the time, there will not be that many. What I propose, is not to don't reach a conclusion, is to provide best of both world !

...

That's why if you really want to put them as list of links, maybe we can change the location and present them more as metadatas.

It is not metadata, you miss my point. What I say is that switching/managing a small list of language is far better served by a list of link then a menu. IMO, this will be the most used case, and the large list will be the exception.

...

Thanks, Caty

On Wed, Sep 24, 2014 at 11:27 AM, Denis Gervalle <[email protected]>

wrote:

...

...

Hi Cathy,

I would like to add a remark to your conclusion which is very

centric on

...

...

the 2.2 solutions.

The main complaints that have been said about 2.1 solution were scalability, and the fear that too much languages could clutter the interface, which is true at some point. However, GL mention the fact that it is really rare to have more than five languages. I also mention that 2.2 solution require more click to switch language.

I would like to add that 2.1 is nearer to what we have actually, so 2.2 could be seen as an important change for existing users. A change that could be seen as less ergonomic. Switching between just two language with 2.2 is really boring compare to the same task with 2.1.

The scalability issue should not drive alone the decision. There is also another aspect of between 2.1 and 2.2 that should be considered. With 2.2, you do not see at a glance, what are the available translations. Two use case here: a) You have to click once to discover that your expected language is not available. b) while reviewing the site for completeness, you need to click to know about available translation for each document.

Believe me, I have work for a long time in multilingual environment, and unless your language usage is very casual, single click switch and direct view of available languages are far more comfortable than a menu choice.

So, since this is still a proposal and not a vote, I think that it is still time to extends the proposal. Why not implementing a mix of 2.1 (for easy of use, and "back compatibility") and 2.2 (for scalability) depending on user configuration, with a default based on the number of configured languages ? It does not look that hard IMO, and could have the benefit of scalability and usability at the same time.

I hope other will reconsider their views, because this is an important choice, and it could make a differentiator for XWiki. WDYT ?

On Tue, Sep 23, 2014 at 4:43 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

> Hi, > > These preferences were so hard to calculate since people didn't used clean > +/-0/1 voted or voted positively on multiple entries, so if I misunderstood > your vote please let me know. > > Reminder: Proposal available at > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

...

> > __Short version__ > > So the majority of the participants liked version 2.2 with some discussion > whether to choose variant 2.2.1 or 2.2.2. > > So the current votes are: > ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) > (+1 Caty) > ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu) > > ** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 > ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1 > > If you want to change your vote or cast another vote, please reply to this > message. Until then, the winning solution is 2.2.1 > > > > __Long version__ > > Some conclusions: > > * 2.1: (-0 Jean) (-1 Sergiu) > ** 2.1.1: (+0 Jean) (+1 Denis) (+0 Silvia) (+0 Manu) > ** 2.1.2: (+1 GL) (+0 Denis) > > * 2.2: (+1 Jean) (+1 Sergiu) > ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) > ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) > ** 2.2.3: (+0 Sergiu) (+0 Andreea) (+0 Manu) > > * 2.3: (-0 Jean) (+/-0 Sergiu) (+0 Andreea) > > * 2.4: (+0 Jean) (+0 Sousa) (-0 Caty) (-1 Sergiu) (+0 Andreea) > > So this means: > > * 2.1: { '1': (-1) (+0) } { '0': (-1) (+0) } = -1 > ** 2.1.1: { '1': (-0) (+1) } { '0': (-0) (+3) } = +1 > ** 2.1.2: { '1': (-0) (+1) } { '0': (-0) (+1) } = +1 > > * 2.2: { '1': (-0) (+2) } { '0': (-0) (+0) } = +2 > ** 2.2.1: { '1': (-0) (+3) } { '0': (-1) (+2) } = +3 > ** 2.2.2: { '1': (-1) (+3) } { '0': (-0) (+1) } = +2 > ** 2.2.3: { '1': (-0) (+0) } { '0': (-0) (+3) } = 0 > > * 2.3: { '1': (-0) (+0) } { '0': (-2) (+2) } = 0 > > * 2.4: { '1': (-1) (+0) } { '0': (-1) (+3) } = -1 > > So the majority of the participants liked version 2.2 with some discussion > whether to choose variant 2.2.1 or 2.2.2. The votes were: > ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) > ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+1 Caty) (-1 Sergiu) > > Adjustments: > > Since Segiu voted -1 on 2.2.2 we couldn't pick this version until the > committer changes his vote, given the arguments. > > Given Sergiu's arguments I want to change my vote for 2.2.2 from +1 -> +0 > and give variant 2.2.1 a +1 vote. > My rationale behind this change is that: > * initially I preferred using links to display the language in order to be > consistent with edit mode (language selection) > * because of space constraints I believe is better to use a menu to display > them > * since it's a menu, I agree it should have the standard menu look > * from an implementation point of view is easier to use the Bootstrap's > menu component than to write a custom one for our case > > So the current votes are: > ** 2.2.1: (-0 Jean) (+1 Sergiu) (+0 GL) (+1 Silvia) (+0 Andreea) (+1 Manu) > (+1 Caty) > ** 2.2.2: (+1 Jean) (+0 Sousa) (+1 GD) (+0 Caty) (-1 Sergiu) > > ** 2.2.1: { '1': (-0) (+4) } { '0': (-1) (+2) } = +4 > ** 2.2.2: { '1': (-1) (+2) } { '0': (-0) (+2) } = +1 > > If you want to change your vote or cast another vote, please reply to this > message. Until then, the winning solution is 2.2.1 > > Thanks, > Caty > > > On Thu, Aug 21, 2014 at 2:31 PM, Manuel Smeria < [email protected]> wrote: > > > Hello, > > > > I'm +1 for this proposal. > > > > I like 2.1.1, 2.2.1 & 2.2.3, but if I were to pick one I'd go with 2.2.1. > > > > Thanks, > > Manuel > > > > > > On Thu, Aug 21, 2014 at 1:29 PM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > > > 2014-08-21 11:00 GMT+02:00 [email protected] < [email protected] : > > > > > > > > > > > > > > > > > > > > > > > On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau ( > > > > [email protected](mailto:[email protected])) wrote: > > > > > > > > > Hi > > > > > > > > > > 2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) : > > > > > > > > > > > Hi, > > > > > > > > > > > > First of all we need to decide how prominent we want this > > > > functionality to > > > > > > be. > > > > > > I would make it more transparent, since theoretically you should > > > change > > > > > > your language preference just once (in the Administration, and > per > > > > user) > > > > > > and all the pages should be displayed according to that > preference. > > > > This is > > > > > > not something that need to be highly visible and that you would > > > change > > > > > > every day. > > > > > > > > > > > > > > > It's not true on a public wiki (like Wikipedia). > > > > > > > > That’s a good point, we need to agree which skin we’re discussing. > > AFAIK > > > > we’re discussing Flamingo which is NOT a public web site skin. When > we > > > do a > > > > public web site skin we would need to take this into consideration > > > indeed. > > > > > > > > > > To me Flamingo can be used for a public wiki (without the app bar), > which > > > has not the same meaning as "public website" which is not necessary a > > > "wiki" (see: > > > http://extensions.xwiki.org/xwiki/bin/view/Extension/Leiothrix+Skin ). > > > > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > IMO it's more important to be better displayed when you want to > > > > > > create a new translation, than when you read one. > > > > > > > > > > > > Regarding the flag to represent languages you can read this > comment > > > > with > > > > > > additional information about why we wouldn't do it like that > > > > > > > > > > > > > > > > > > > > > >

http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com.atla...

...

...

...

...

...

> > > > > > > > > > > > Thanks, > > > > > > Caty > > > > > > > > > > > > > > > > > > On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle wrote: > > > > > > > > > > > > > Hi Cathy, > > > > > > > > > > > > > > 2.1.1 is the one I prefer, 2.1.2 is also good but the > separation > > > > between > > > > > > > language should be more clear, and it is less easy to see the > > > active > > > > > > one. I > > > > > > > have no fear about the scaling issue, even heavily multilingual > > > site > > > > like > > > > > > > those of the European Commission use such enumeration without > > > issue. > > > > And > > > > > > as > > > > > > > Guillaume said, it is really rare to have more than a few > > languages > > > > > > anyway. > > > > > > > Other proposal implies multiple click/touch for the same > purpose, > > > > which > > > > > > is > > > > > > > bad IMO for content. It is also important to only display > > > effectively > > > > > > > available languages, but with an enum, it could be also good to > > > have > > > > the > > > > > > > option to also display unavailable one greyed, so language keep > > > their > > > > > > > location on screen. > > > > > > > > > > > > > > Regarding the UI language, 1.1 is fine, but maybe a bit large. > > > Having > > > > > > only > > > > > > > initial in the bar would be better IMO. Having also a more > fancy > > > > > > solution, > > > > > > > like what I have done with bluebird (see http://softec.lu ), > > could > > > be > > > > > > nice > > > > > > > to have as well... or a easy way to customize it that way with > an > > > > > > > extension. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Aug 18, 2014 at 5:34 PM, Ecaterina Moraru (Valica) < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > Hi devs, > > > > > > > > > > > > > > > > We have http://jira.xwiki.org/browse/XWIKI-10745 (Improve > the > > > > display > > > > > > of > > > > > > > > available languages in Flamingo) which is related to > > > > > > > > http://jira.xwiki.org/browse/XWIKI-6402 (Separate Interface > > > > language > > > > > > and > > > > > > > > page language settings) > > > > > > > > > > > > > > > > While in Flamingo we could just make the language links look > > > > better, > > > > > > > > without changing the functionality, for the future, the > > > separation > > > > is > > > > > > > > something we might want to tackle, that's why I've created > this > > > > > > proposal > > > > > > > > page > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguageS...

...

...

...

...

...

> > > > > > > > > > > > > > > > I am interested in what you think about the variants. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Caty > > > > > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs