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/InterfaceAndContentLanguageSeparation > >> > > > >> > > __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.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-77895 > >> > > > > > > > > >> > > > > > > > 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/InterfaceAndContentLanguageSeparation > >> > > > > > > > > > > >> > > > > > > > > > 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
