Re: [xwiki-devs] [xwiki-users] [UX][Proposal] Administration Overview

[Sergiu Dumitriu]

Ah, finally something useful instead of duplicating the menu. Some
suggestions:

- The version alone is not enough; which product, and what flavor?

- The proposed status is too "static", IMHO. It describes the size of
the wiki, but not its health. I'd like to see active status as well:
* 123 users (3 active in the last week)
** Perhaps also mention groups?
* 67 pages (7 updated in the last week)
* 12324 page views (143 in the last week)
* 562 visitors (42 in the past week)
* Top 10 popular pages
I know that not all this information is easy to compute (or even
possible), so it's just a "nice to have" list

- This should be extensible, so that extensions can add their own
summary information.

- Should apps be allowed to list their own summary? Like: "23 blog posts
(2 new in the last week)" if the blog application is installed.

- Typo: paid, not payed

- What exactly is the community address? Is it the users list, or
something new?

- It would be nice to display security information here:
* Updates available
* Weak settings (the Admin password is still "admin", "superadmin" is
enabled, cookie encryption keys are not randomized, public comments
enabled...)
* Many failed passwords detected
* Comment spam detected

On 12/09/2016 11:05 AM, Ecaterina Moraru (Valica) wrote:
> http://design.xwiki.org/xwiki/bin/view/Proposal/AdministrationOverview
> 
> On Fri, Dec 9, 2016 at 6:04 PM, Ecaterina Moraru (Valica) > wrote:
> 
>> Hi,
>>
>> This is a idea proposal for an Administration Overview that:
>> A. Provides generic/global information about the instance like 'version',
>> 'instance id', etc.
>> B. Provides a summary of usage listing count of major entities (wikis,
>> users, pages, extensions, etc.)
>> C. Lists demo content installed in the wiki
>> D. Provides a way for administrators to subscribe to the XWiki Community
>>
>> I'm curios which of the above section sounds interesting to you and would
>> like to see inside the product. Also maybe you have other ideas of what is
>> missing or could be represented better.
>>
>> Thanks,
>> Caty
>>


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/

Re: [xwiki-devs] [XWiki Day] BFD#130

[Alexandru Cotiuga]

Results: http://www.xwiki.org/xwiki/bin/view/Blog/Bug+Fixing+Day+130.

Thanks,
Alex

On Thu, Dec 8, 2016 at 8:51 AM, Alexandru Cotiuga <
alexandru.coti...@xwiki.com> wrote:

> Hello devs,
>
> Today is BFD#130:
> http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
>
> Our current status for the 1 year period is 32 bugs behind. See:
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100
> 00#Created-vs-Resolved-Chart/10470
>
> Here's the BFD#130 dashboard to follow the progress during the day:
> http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13712
>
> Enjoy a new BugFixing Day,
> Alex
>

[xwiki-devs] [UX][Proposal] Administration Overview

[Ecaterina Moraru (Valica)]

Hi,

This is a idea proposal for an Administration Overview that:
A. Provides generic/global information about the instance like 'version',
'instance id', etc.
B. Provides a summary of usage listing count of major entities (wikis,
users, pages, extensions, etc.)
C. Lists demo content installed in the wiki
D. Provides a way for administrators to subscribe to the XWiki Community

I'm curios which of the above section sounds interesting to you and would
like to see inside the product. Also maybe you have other ideas of what is
missing or could be represented better.

Thanks,
Caty

Re: [xwiki-devs] [UX][Proposal] Administration Overview

[Ecaterina Moraru (Valica)]

http://design.xwiki.org/xwiki/bin/view/Proposal/AdministrationOverview

On Fri, Dec 9, 2016 at 6:04 PM, Ecaterina Moraru (Valica)  wrote:

> Hi,
>
> This is a idea proposal for an Administration Overview that:
> A. Provides generic/global information about the instance like 'version',
> 'instance id', etc.
> B. Provides a summary of usage listing count of major entities (wikis,
> users, pages, extensions, etc.)
> C. Lists demo content installed in the wiki
> D. Provides a way for administrators to subscribe to the XWiki Community
>
> I'm curios which of the above section sounds interesting to you and would
> like to see inside the product. Also maybe you have other ideas of what is
> missing or could be represented better.
>
> Thanks,
> Caty
>

Re: [xwiki-devs] [BackwardCompatibility] Breakage in translations for Copy/Rename/Move

[Eduard Moraru]

On Thu, Dec 8, 2016 at 11:36 PM, Vincent Massol  wrote:

> Hi Edy,
>
> > On 8 Dec 2016, at 21:13, Eduard Moraru  wrote:
> >
> > Hi,
> >
> > Now, I`m not sure of all the details, but what I remember is that they
> were
> > a handful of keys that were recently introduced (Nested Spaces work) and
> > deprecating them did not seem very justified at the time.
>
> Well apparently they were quite spaced out from XWiki 7.2M3 to
> 7.4.3/8.0RC1.
>
> > I considered that
> > we would start dragging them along when they were too young to have been
> > used.
> >
> > I had fixed the FR and NL translations (only ones existing) on
> > l10n.xwiki.org for the rename action, however I did seem to have missed
> the
> > copy action [1].
>
> Actually I spent some hours fixing the FR translations some week(s) ago as
> they were broken in the same way as the copy action is now (I’m fixing
> that, spent some time today to fix stuff on l10n this morning and then got
> stopped by other things but I’m planning to finish fixing the FR
> translations).
>
> Somehow I introduced some errors when I fixed the FR translations back
> then, by using the unicode escapes instead of accented characters and this
> resulted in [2] (which I have fixed this morning).
>
> But I didn’t check the other translations. I’ll leave that to you if
> you’re ok.
>
> > The screenshot [2] from the rename action does not really look like the
> > same thing. It seems to be a bad choice of accented characters that needs
> > to be replaced with something standard, something that can happen in any
> > translation and that is not particularly related to the change of the EN
> > key`s value.
> >
> > I am perfectly aware of the general rule and I agree with it.
> >
> > AFAICT, the only affected languages were FR and NL.
>
> Could you check that? Note that I had to fix the FR translations a while
> back to remove the CHOICE constructs since that was not leading to good
> results in French. I don’t remember the details though.
>
> > IMO, the solution is to fix the l10n translations for those languages and
> > include them in the next release of 7.x, 8.x and 9.x. For the supported
> > branches (other than master), if we don`t want to update the translations
> > during the release, we could manually commit the changes in the
> translation
> > files on git, for the affected keys. Reverting does not make much sense,
> > IMO, since it implies the same, if not more, amount of work to get to a
> > state that still has the original jira issue's problem.
> >
> > WDYT?
>
> Sure, fine with me if you can handle the non-FR translations and the
> branches.
>

I`ll try to make some time next week to review the affected languages and
commit the fixes on the branches.

Thanks and sorry for the inconvenience.

-Eduard


>
> Thanks!
> -Vincent
>
> > Thanks,
> > Eduard
> >
> > --
> > [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg
> > [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg
> >
> > On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu 
> wrote:
> >
> >> This has been there for a lng time:
> >> http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions#
> >> HUpdatingtranslations
> >>
> >> On 12/08/2016 07:46 AM, Vincent Massol wrote:
> >>> Hi devs,
> >>>
> >>> The story
> >>> 
> >>>
> >>> 1) We introduced some new translations keys in
> https://github.com/xwiki/
> >> xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff-
> >> fffbf37334c4d7a178b13f4ccc313f86R746
> >>>
> >>> That was done in XWIKI-12431 (Adapt the "rename" action for nested
> >> documents), i.e. in 7.2M3
> >>>
> >>> 2) We modified the keys in https://github.com/xwiki/
> >> xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
> >>>
> >>> That was done in XWIKI-13067 ("Rename: Change the label to make it
> clear
> >> that both links and backlinks are updated or have 2 separate options”),
> >> i.e. in XWiki 8.0-rc-1, 7.4.3
> >>>
> >>> 3) The consequence is that all translations got broken, resulting in
> >> problems such as http://jira.xwiki.org/browse/XINFRA-219. However this
> >> issue reports the issue only for French but it’s likely that it broke
> the
> >> translations for other languages.
> >>>
> >>> The learnings
> >>> ===
> >>>
> >>> 1) We must never change the format of existing translation keys. This
> is
> >> the equivalent of breaking an API. Instead we need to go through
> >> deprecation of existing keys and introduction of new keys, even though
> it’s
> >> a pain. http://dev.xwiki.org/xwiki/bin/view/Community/
> >> DevelopmentPractices#HTranslationBestPractices would probably benefit
> >> from additional explanations too.
> >>>
> >>> 2) We would need a tool in the quality profile of our build/CI that
> >> would break the build if someone changes the format of a
> >> translation.Easiest would be a tool that compares the English
> translations
> >> on master vs 

Re: [xwiki-devs] [BackwardCompatibility] Breakage in translations for Copy/Rename/Move

[Vincent Massol]

FYI I’ve now fixed the FR translations and closed 
http://jira.xwiki.org/browse/XINFRA-219

Thanks
-Vincent

> On 8 Dec 2016, at 22:36, Vincent Massol  wrote:
> 
> Hi Edy,
> 
>> On 8 Dec 2016, at 21:13, Eduard Moraru  wrote:
>> 
>> Hi,
>> 
>> Now, I`m not sure of all the details, but what I remember is that they were
>> a handful of keys that were recently introduced (Nested Spaces work) and
>> deprecating them did not seem very justified at the time.
> 
> Well apparently they were quite spaced out from XWiki 7.2M3 to 7.4.3/8.0RC1.
> 
>> I considered that
>> we would start dragging them along when they were too young to have been
>> used.
>> 
>> I had fixed the FR and NL translations (only ones existing) on
>> l10n.xwiki.org for the rename action, however I did seem to have missed the
>> copy action [1].
> 
> Actually I spent some hours fixing the FR translations some week(s) ago as 
> they were broken in the same way as the copy action is now (I’m fixing that, 
> spent some time today to fix stuff on l10n this morning and then got stopped 
> by other things but I’m planning to finish fixing the FR translations).
> 
> Somehow I introduced some errors when I fixed the FR translations back then, 
> by using the unicode escapes instead of accented characters and this resulted 
> in [2] (which I have fixed this morning).
> 
> But I didn’t check the other translations. I’ll leave that to you if you’re 
> ok.
> 
>> The screenshot [2] from the rename action does not really look like the
>> same thing. It seems to be a bad choice of accented characters that needs
>> to be replaced with something standard, something that can happen in any
>> translation and that is not particularly related to the change of the EN
>> key`s value.
>> 
>> I am perfectly aware of the general rule and I agree with it.
>> 
>> AFAICT, the only affected languages were FR and NL.
> 
> Could you check that? Note that I had to fix the FR translations a while back 
> to remove the CHOICE constructs since that was not leading to good results in 
> French. I don’t remember the details though.
> 
>> IMO, the solution is to fix the l10n translations for those languages and
>> include them in the next release of 7.x, 8.x and 9.x. For the supported
>> branches (other than master), if we don`t want to update the translations
>> during the release, we could manually commit the changes in the translation
>> files on git, for the affected keys. Reverting does not make much sense,
>> IMO, since it implies the same, if not more, amount of work to get to a
>> state that still has the original jira issue's problem.
>> 
>> WDYT?
> 
> Sure, fine with me if you can handle the non-FR translations and the branches.
> 
> Thanks!
> -Vincent
> 
>> Thanks,
>> Eduard
>> 
>> --
>> [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg
>> [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg
>> 
>> On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu  wrote:
>> 
>>> This has been there for a lng time:
>>> http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions#
>>> HUpdatingtranslations
>>> 
>>> On 12/08/2016 07:46 AM, Vincent Massol wrote:
 Hi devs,
 
 The story
 
 
 1) We introduced some new translations keys in https://github.com/xwiki/
>>> xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff-
>>> fffbf37334c4d7a178b13f4ccc313f86R746
 
 That was done in XWIKI-12431 (Adapt the "rename" action for nested
>>> documents), i.e. in 7.2M3
 
 2) We modified the keys in https://github.com/xwiki/
>>> xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
 
 That was done in XWIKI-13067 ("Rename: Change the label to make it clear
>>> that both links and backlinks are updated or have 2 separate options”),
>>> i.e. in XWiki 8.0-rc-1, 7.4.3
 
 3) The consequence is that all translations got broken, resulting in
>>> problems such as http://jira.xwiki.org/browse/XINFRA-219. However this
>>> issue reports the issue only for French but it’s likely that it broke the
>>> translations for other languages.
 
 The learnings
 ===
 
 1) We must never change the format of existing translation keys. This is
>>> the equivalent of breaking an API. Instead we need to go through
>>> deprecation of existing keys and introduction of new keys, even though it’s
>>> a pain. http://dev.xwiki.org/xwiki/bin/view/Community/
>>> DevelopmentPractices#HTranslationBestPractices would probably benefit
>>> from additional explanations too.
 
 2) We would need a tool in the quality profile of our build/CI that
>>> would break the build if someone changes the format of a
>>> translation.Easiest would be a tool that compares the English translations
>>> on master vs the last released version and breaks if there’s a difference
>>> in parameter (i.e. {N} syntax).
 
 3) We need to decide