1 Oct
2014
1 Oct
'14
12:38 a.m.
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 <dgl(a)softec.lu> wrote:
On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
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 <dgl(a)softec.lu> wrote:
->
+0
wrote:
and
http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com…
without
(Valica) <
created
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
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) <
valicac(a)gmail.com> wrote:
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
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
__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 > 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
Bootstrap's
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 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 <manuel(a)xwiki.com>
> 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 <
> gdelhumeau(a)xwiki.com> wrote:
>
> > 2014-08-21 11:00 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net
:
> >
> > >
> > >
> > >
> > >
> > > On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
> > > gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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,
> 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
> > > > >
> > > > >
> > >
> >
>
> > > > > >
> > > > > > 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
> > > 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
> > > > > > >
valicac(a)gmail.com> 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 this
> > > > > proposal
> > > > > > > page
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
> >
> > > > >
> > > > > > > I am interested in what you think about the variants.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Caty
> > >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs