18 Aug
2014
18 Aug
'14
5:34 p.m.
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/InterfaceAndContentLanguage…
I am interested in what you think about the variants.
Thanks,
Caty
18 Aug
18 Aug
5:54 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
All propositions are nice. However, this is my point of view.
# Variant 2.1:
Enumeration probably isn't a good option; it works when you have 2 languages, it
begins to cause problems when you have 20 (visual annoyance, possible problem of
UI alignement)
but visual of 2.1.1 is nice :-)
# Variant 2.2:
This is my preferred view. I'm not sure which one of the subvariant is the best
but I would eliminate the first one for the same reason as 2.3 (see below).
However, the user will click in order to load another page/content, then a link
like 2.2.2 would be better?
# Variant 2.3:
I'm against adding another big button in the UI. The strength of Flamingo is
for me that it is far more visually light that Colibri.
# Variant 2.4:
This seems to be a good solution, as well as 2.2. Just personal, I would go for
the 2.2 instead of 2.4 because language is part of the content and should be
displayed without clicking on a button.
This is only my point of view.
Hope this helps.
On Mon, Aug 18, 2014 at 06:34:26PM +0300, Ecaterina Moraru (Valica) 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/InterfaceAndContentLanguage…
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
--
Jean SIMARD <jean.simard(a)xwiki.com>
6:51 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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!?
19 Aug
19 Aug
9:30 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hi,
Thanks everyone for your comments.
On Mon, Aug 18, 2014 at 7:51 PM, O.J. Sousa Rodrigues <
osoriojaques(a)gmail.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Aug
18 Aug
6:52 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hi Caty.
Nice proposal.
I personally like the variants 2.2.2 and 1.1, with a preference for 2.2.2.
Thanks,
Guillaume
2014-08-18 17:54 GMT+02:00 Jean SIMARD <jean.simard(a)xwiki.com>om>:
All propositions are nice. However, this is my point
of view.
# Variant 2.1:
Enumeration probably isn't a good option; it works when you have 2
languages, it
begins to cause problems when you have 20 (visual annoyance, possible
problem of
UI alignement)
but visual of 2.1.1 is nice :-)
# Variant 2.2:
This is my preferred view. I'm not sure which one of the subvariant is
the best
but I would eliminate the first one for the same reason as 2.3 (see below).
However, the user will click in order to load another page/content, then a
link
like 2.2.2 would be better?
# Variant 2.3:
I'm against adding another big button in the UI. The strength of Flamingo
is
for me that it is far more visually light that Colibri.
# Variant 2.4:
This seems to be a good solution, as well as 2.2. Just personal, I would
go for
the 2.2 instead of 2.4 because language is part of the content and should
be
displayed without clicking on a button.
This is only my point of view.
Hope this helps.
On Mon, Aug 18, 2014 at 06:34:26PM +0300, Ecaterina Moraru (Valica) 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/InterfaceAndContentLanguage…
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
--
Jean SIMARD <jean.simard(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Aug
19 Aug
7:46 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
On 08/18/2014 11:34 AM, Ecaterina Moraru (Valica) 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/InterfaceAndContentLanguage…
I am interested in what you think about the variants.
2.1 doesn't scale well.
2.2 is clean and simple (especially 2.2.3), but it's not as easy to notice.
Like Jean said, 2.3 makes the menu cluttered, but on the other hand it
is visible enough not to be missed.
2.4 is not easy to find, it hides the translations behind a menu.
-1 for 2.1 and 2.4. Between 2.2 and 2.3, I think people only need to
discover the translation feature once, while the big menu button will
always take up space. So +1 for 2.2.
-1 for 2.2.2, that's a menu and not a link.
Between 2.2.1 and 2.2.3, I find that 2.2.3 is not obvious enough. Are
there any other elements in the skin that implement selections as a
simple text? If not, then for consistency we should use 2.2.1. Users are
used to certain controls, and I'm not sure the most non-technical of our
users will know that they can click on that item even if doesn't look
like a drop down.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
20 Aug
20 Aug
5:45 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hi,
nice proposal. I agree that separating interface language management from
content language management will be a welcome improvement :-)
1.1 looks good.
I like 2.1.2. The case of 5+ languages in unlikely to happen a lot.
2.2.1 looks good as well.
Thanks,
Guillaume
On Tue, Aug 19, 2014 at 7:46 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote:
On 08/18/2014 11:34 AM, Ecaterina Moraru (Valica)
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/InterfaceAndContentLanguage…
I am interested in what you think about the variants.
2.1 doesn't scale well.
2.2 is clean and simple (especially 2.2.3), but it's not as easy to notice.
Like Jean said, 2.3 makes the menu cluttered, but on the other hand it
is visible enough not to be missed.
2.4 is not easy to find, it hides the translations behind a menu.
-1 for 2.1 and 2.4. Between 2.2 and 2.3, I think people only need to
discover the translation feature once, while the big menu button will
always take up space. So +1 for 2.2.
-1 for 2.2.2, that's a menu and not a link.
Between 2.2.1 and 2.2.3, I find that 2.2.3 is not obvious enough. Are
there any other elements in the skin that implement selections as a
simple text? If not, then for consistency we should use 2.2.1. Users are
used to certain controls, and I'm not sure the most non-technical of our
users will know that they can click on that item even if doesn't look
like a drop down.
--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:37 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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) <
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
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
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
--
Denis Gervalle
SOFTEC sa - CEO
21 Aug
21 Aug
9:58 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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. 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…
Thanks,
Caty
On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle <dgl(a)softec.lu> 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) <
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
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
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
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:17 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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
10:41 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hello,
I'm +1 for the this proposal.
I like pretty much these variants: 2.2.1, 2.2.3, 2.3 and 2.4.
Andreea
On Thu, Aug 21, 2014 at 11:17 AM, Silvia Rusu <silvia.rusu(a)xwiki.com> wrote:
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:56 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hi
2014-08-21 9:58 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
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…
Thanks,
Caty
On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Guillaume
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) <
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
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 a.m.
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) :
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.
Thanks
-Vincent
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…
>
> 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) <
> > 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
> > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > >
> > > I am interested in what you think about the variants.
> > >
> > > Thanks,
> > > Caty
11:10 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
On Thu, Aug 21, 2014 at 12:00 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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
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).
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…
>
> 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) <
> > 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
> > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > >
> > > 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
11:55 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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.
On Thu, Aug 21, 2014 at 12:10:32PM +0300, Ecaterina Moraru (Valica) wrote:
On Thu, Aug 21, 2014 at 12:00 PM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
--
Jean SIMARD <jean.simard(a)xwiki.com>
On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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
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).
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs > 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…
>
> 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) <
> > 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
> > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > >
> > > 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
12:21 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
On Thu, Aug 21, 2014 at 11:55 AM, Jean SIMARD <jean.simard(a)xwiki.com> 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:
We are discussing any default skin with Localization - Multilinguage - Yes.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean SIMARD <jean.simard(a)xwiki.com>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
On Thu, Aug 21, 2014 at 12:00 PM,
vincent(a)massol.net <vincent(a)massol.net
wrote:
>
>
>
>
> 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, 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.
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…
> > >
> > > 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) <
> > > > 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
> > > > >
> > > > >
> > > >
> > >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > >
> > > 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
12:29 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
2014-08-21 11:00 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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 ).
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).
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…
>
> 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) <
> > 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
> > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > >
> > > 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
1:31 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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>et>:
change
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
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…
> > > > > 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
> > > >
Regarding the UI language, 1.1 is fine, but maybe a bit large.
Having
> > > >
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
> > > > > > >
> > > > > >
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > > > > > > >
> 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
On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
change
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 > 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 every day.
It's not true on a public wiki (like Wikipedia). public web site skin we would need to take this
into consideration
indeed.
> > 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
effectively
> 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 > > > 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.
> > > > > 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.
> > >
23 Sep
23 Sep
4:43 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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/InterfaceAndContentLanguage…
__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 <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:
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…
active
languages
effectively
could
_______________________________________________
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
2014-08-21 11:00 GMT+02:00 vincent(a)massol.net
<vincent(a)massol.net>et>:
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
On 21 Aug 2014 at 10:57:36, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
change
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 > 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 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.
>
> 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 > > 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 > anyway.
> > Other proposal implies multiple click/touch for the same purpose,
which
> > is
> > > bad IMO for content. It is also important to only display > > > 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), be
separation
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
>
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 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
4:57 p.m.
On 23 Sep 2014 at 16:44:39, Ecaterina Moraru (Valica)
(valicac@gmail.com(mailto:valicac@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.
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/InterfaceAndContentLanguage…
__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 <
gdelhumeau(a)xwiki.com> wrote:
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…
languages
could
_______________________________________________
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 2014-08-21 11:00 GMT+02:00 vincent(a)massol.net :
AFAIK
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, 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. 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.
>
>
> > 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 > >
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), be
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > 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
5:16 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
2014-09-23 16:57 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
On 23 Sep 2014 at 16:44:39, Ecaterina Moraru (Valica) (valicac(a)gmail.com
(mailto:valicac@gmail.com)) wrote:
Concerning 2.2.1, it is better than that. It only appears if the current
document has translations.
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
_______________________________________________
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
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reminder: Proposal available at
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
__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 <
> gdelhumeau(a)xwiki.com> wrote:
>
> > 2014-08-21 11:00 GMT+02:00 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, 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…
> > > > >
> > > > > 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)
<
> > > > > > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > > > >
> > > > > 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
24 Sep
24 Sep
10:27 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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:
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/InterfaceAndContentLanguage…
__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 <manuel(a)xwiki.com> wrote:
AFAIK
> > we’re discussing Flamingo which is NOT a public web site skin. When we
http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com…
languages
> > > > anyway.
> > > > > Other proposal implies multiple click/touch for the same
purpose,
an
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
_______________________________________________
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
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>et>:
>
> >
> >
> >
> >
> > 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, 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. > 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 without
issue.
> And
> > > as
> > > > Guillaume said, it is really rare to have more than a few > > 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
> > > > > 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
10:49 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
Hi,
Depends who is our main focus: normal users or content gardeners?
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).
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.
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.
----
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.
The argument that there are not that many languages in the wild is hard to
quantify, since we are missing user statistics.
---
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.
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.
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 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:
we
).
http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com…
multilingual
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
with
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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/InterfaceAndContentLanguage…
__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 <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>et>:
> >
> > >
> > >
> > >
> > >
> > > 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, 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 > 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 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 > > 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
an
Interface
> > > > > 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
> > > 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
11:53 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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 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
<
created
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
--
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
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
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 <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
(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 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
1 Oct
1 Oct
12:38 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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
9:09 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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>:
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:
that
are
fallback
of
visible
a
--
Denis Gervalle
SOFTEC sa - CEO
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
available
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 > 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 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 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 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 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 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 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 !
list
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 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:
>
> > 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:
> >
> > > 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/InterfaceAndContentLanguage…
> > >
> > > __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 <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 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,
> 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…
> > > > > > > >
> > > > > > > > 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) <
> > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
> > > > > > > >
> > > > > > > > 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
9:22 a.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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:
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>:
language, I
displayed
kind
see
list
> of link then a menu. IMO, this will be the most used case, and the large
With
is
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
(+1
+1
with
(
http://jira.xwiki.org/browse/XWIKI-9512?focusedCommentId=77895&page=com…
same
also
bit
http://design.xwiki.org/xwiki/bin/view/Proposal/InterfaceAndContentLanguage…
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
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
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:
fallback
On Wed, Sep 24, 2014 at 10:49 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
available
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 > 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 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 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) >> 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
of
of
> links for years now, so we are talking about a major change for
existing
> 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 > 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 a
an
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 > 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 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
that
> > 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 > >
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. > 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 >> 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 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)
>> > 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
>> -> +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
<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 > >
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,
>> 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
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> >
> > > > > >
> > > > > > > > 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 > >
> 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 > >
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) <
> > > > > > > > > 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
3:46 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
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
21 Aug
21 Aug
12:14 p.m.
New subject: [xwiki-devs] [Proposal] Interface and Content Language Separation
On Thu, Aug 21, 2014 at 9:58 AM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
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.
I do agree for the UI language, I absolutely not seing the content language
that way. In particular, collaboration on multilingual project really need
to easily change languages and see what is available at a glance.
IMO it's more important to be better displayed
when you want to
create a new translation, than when you read one.
For this kind of purpose, I would suggest to have a simplified language
management where UI and content language are more tightly linked in view
mode, and managed from a single choice using a 1.1 UI
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…
I know already about that, this is what I mean by fancy. It is not only a
matter of being rigorous here but also to provide flexibility, since it
depends on purposes. As I said, it should not be standard, but it should be
feasible through extensions.
Thanks,
Thanks,
Caty
On Wed, Aug 20, 2014 at 9:37 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
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,
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) <
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
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3638
days inactive
3682
days old
28 comments
12 participants
participants (12)
-
Andreea Popescu -
Denis Gervalle -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Guillaume Lerouge -
Jean SIMARD -
Manuel Smeria -
O.J. Sousa Rodrigues -
Sergiu Dumitriu -
Silvia Rusu -
vincent＠massol.net