1 Oct
2014
1 Oct
'14
3:46 p.m.
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 <dgl(a)softec.lu> 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 <
gdelhumeau(a)xwiki.com> wrote:
fallback
when
languages
a
called
conclusion.
he
PT-BR"
language
Two
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
reply
until
look
reply
Delhumeau
app
http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com…
also
bit
> >> > large.
> >> > > > > Having
> >> > > > > > > > only
> >> > > > > > > > > initial in the bar would be better
IMO. Having also a
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
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
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 <dgl(a)softec.lu>lu>:
wrote:
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>
On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> 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 >> 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 > > 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 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 >
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 >
"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 > >>
> >
> > 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
>>
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
an
> > issue. To compare, do you think that a button labelled "Brazilian
> > Portuguese" is more or less cumbersome than the list "EN | FR |
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 ?
> > Remember that we could display only available translations, and
unless
we
best
> 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 of
large
the
> 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 > list will be the exception.
>
>
>>
>> Thanks,
>> Caty
>>
>>
>>
>> On Wed, Sep 24, 2014 at 11:27 AM, Denis Gervalle <dgl(a)softec.lu>
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 > >> > 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 > >> 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.
> 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
is
> > 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 >> 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:
>> >
>> > > 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
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
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
>>
> > * 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
> 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>
>>
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 <
> >> > > > 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
(
that
>> > > > > >
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,
> >> and
> >> > > per
> >> > > > > > user)
> >> > > > > > > > and all the pages should be displayed
according to >>
> > 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 > >> 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
> >> 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 > 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 > 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) <
> >> > > > > > > > > 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
> created
> > > 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
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Denis Gervalle
SOFTEC sa - CEO
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs