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
