Hello devs,
I need your opinion on how we should import new components (i.e.
translations) into Weblate <http://l10n.xwiki.org>.
Weblate allows you to create components directly on their platform but it
will be very difficult for us to so because we would have to run an import
script to generate translation files and then fill in many error prone
information.
So what I was thinking of was to create a script which will just read a
file where each line contains:
1. The component name
2. The base translation file path (english translation file)
3. The repository url
It will then create or import the component automatically based on these
lines.
The downside is that you'll have to modify a file each time you want to
create (or delete) a component and you'll have to execute the script from
the server.
WDYT?
Thanks,
Adel
Hi,
Following my previous email on "How should we review translations?", I'd
like to know here if we should support automatic multibranch translations
in Weblate.
What I mean here is that with the old l10n platform, we would apply new
translations on multiple git branches (for some projects like XWiki
Platform). It was important to have new translations applied on LTS
releases and other branches.
The problem is that we can't tell Weblate to automatically push changes on
multiple branches. We have discuss the problem with the maintainer here:
https://github.com/WeblateOrg/weblate/issues/2016.
What we can do is to duplicate Weblate components (a component is just a
file to translate) for as many branches as we need. Making a change to a
translation key (e.g. tour.homepageTour.pageMenu.contentB) will propagate
the change to every other components with the same key. This way we can
have a PR made with the same change on every branch we want.
So here are the two options:
1) We keep the actual behavior
Pros:
- We will only have one PR to review (on master branch)
Cons:
- We will have to apply new changes to other branches ourselves when
needed
2) We duplicate components
Pros:
- Changes will automatically be made for every specified branches
Cons:
- Some work to do: we can't create all the new components by hand so we
will have to generate every components in some way
- It will make Weblate much more complex because you can't hide
components (https://i.imgur.com/YJ8qtUz.png)
I prefer option 1 because it will make Weblate easier to use.
For option 2, we can also disable translation propagation and let people
make translations on the branch they want.
Thanks,
Adel
The XWiki development team is proud to announce the availability of XWiki 10.4.
In this version we've improved the Navigation panel by allowing pages to be
excluded from the listing. We've added a new macro for Notifications that
allows it to be embedded in other pages. We've also improved the History's
Changes view by providing more navigation options between versions. We've
continued to tweak the edit protection, added in the previous version, for
some default extension pages (like Skin, Color Themes, Dashboard, Sandbox,
etc.).
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/10.4/
Thanks for your support
-The XWiki dev team
Hi all!
This mail is a request for the creation of a new contrib project named
blockly-editor-application, which adds a Google Blockly code editor to
XWiki.
Just as an FYI, my GitHub username is Remorax :)
Please do the needful and get back to me ASAP!
Thanks and regards,
Vivek Iyer
Hi everyone,
I just realized that:
1) we're not testing WCAG as part of our QA efforts (we have some basic WCAG automated tests but they cover only a small part - see http://dev.xwiki.org/xwiki/bin/view/Community/WCAGTesting). For ex we don't test how readable our UIs are with a screen reader and how user can use the UI without the mouse.
2) As we progress and make our UIs more "usable", for example by replacing input fields with nice drag and drop UIs (see Applications Panel, the new Nav Panel Admin in 10.5, etc), we actually make our UIs less usable for persons with disabilities
3) We can always argue that everything can also be done by using the object editor and thus we have a fallback. We have a way in the user profile to indicate that the user is requesting accessibility. However when active, we don't change the UI in lots of places (for example in the App Panel admin UI, we don't point link to the object editor instead of displaying the drag&drop).
So I was wondering if we wanted to have a plan/direction for this.
Seen the manpower we have I think we need to do the simplest thing that can work. The objet editor is a good direction IMO.
So IMO, if we wanted to improve XWiki accessibility, we should do:
A) Have someone test with a screen reader and report issues
B) Have someone test without the mouse and report issues
C) Review places in the UI where we should check if accessibility is active for the current user and if so, fallback to some links to the object editor with some explanation text. Report issues
WDYT?
Thanks
-Vincent
PS: I’m not saying we should do this now, but more making sure we have a plan we agree on.
Hi xwikiers,
In 10.3 I introduced a "home" type with Main.WebHome in mind with the
following defaults:
* edit allow
* delete forbidden
* no upgrade if modified
I tough that deleting the wiki home page was not so great.
Eduard argue that since the wiki home page is configurable there is no
reason to restrict delete right.
WDYT ?
I feel that most people don't change the configured home page so I'm
+1 to keep it like this but I'm not strongly against allowing delete
if others think it's fine since I don't have much experience with
configured home page use case.
--
Thomas Mortagne
Hello everyone,
As you probably know, we have decided to use Weblate <https://weblate.org/> as
our new translation platform (l10n.xwiki.com). We still need to make some
decisions before making an official announcement to the community.
I'd like to know here how we should deal with translation reviews.
I'm thinking of two ways to review translations:
1) Reviewing directly on the Weblate platform
Pros:
- Users can only make suggestions for already approved translations
(which means we'll only have approved translations in the commits)
- We can compare the translated keys to the source one (English)
- We could push commits directly on the git repository instead of making
PRs
Cons:
- AFAICS we can only review one translation key at a time (and overall
the review process seems to be quite hard)
- It seems that we receive an email for each new suggestions/translations
(and we can't group them)
2) Reviewing on Github (with PRs)
Pros:
- We can review everything in a single view (github diff)
- We know exactly what we are merging in the repository
Cons:
- Can't see the English source next to the translation (even if we mostly
don't need to)
- It's harder to manage spam as people could change every translations
(no locking/suggestions)
- You'll have to go on Weblate and revert rejected keys (one by one)
I'm in favor of option 2 as it's the simplest and the safest one as
everything can be checked on the PR.
If you need to see how reviews are being made on Weblate, I can probably
send screenshots or just give, for some of you, manager rights on the
platform.
WDYT?
Thanks,
Adel
On Fri, May 18, 2018 at 9:35 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> On Thu, May 17, 2018 at 10:10 PM, Kwan Kim <kwk9002(a)nyp.org> wrote:
>> I am Kwan Kim who works for the Rogosin Institute (medical research company specialized for Kidney disease in New York)
>>
>> Recently we tried to use xwiki as an our wiki server.
>>
>> So we configured the xwiki server on Redhat, MySQL & Glassfish environment and ask vulnerability test team to test.
>>
>> However they found several security issues.
>>
>> And I am not a expert for the xwiki so I am not sure whether xwiki already has a solution to fix the issues or not.
>>
>> That’s why I would like to ask you about the security features of xwiki.
>>
>> This is the security problems which the vulnerability team addressed below:
>>
>> 1. Cross Site Scripting (XSS): Script insertion at Name Field in the registration form.
>>
>> When new user register, there is first and last name field. thesis fields allow javascript code.
>
> It's not very clear to me what this mean. In which context exactly the
> javascript inserted in the user name is executed ?
The inserted javascript can be found on the profile page. See this
screenshot for instance: https://i.imgur.com/NNcSFb0.png
We could either escape HTML tags whenever first name and last name
fields are displayed or we can escape the tags directly when saving
the information on the database (but we'll need to make a migration).
>
>>
>> Is there any way we can put the some validation to prevent the javascript code ?
>>
>>
>> 2. No controls for Account Creation
>>
>> The vulnerability test team think it is too easy to create new account
>>
>> Is there any way that new account need to get approval from admin user ?
>
> Its possible to disable registration and let admins create accounts
> but I don't think there is any support for admin validation of self
> registered users (but it's possible I missed it).
>
>>
>>
>> 3.Site discloses session tokens in multiple locations
>>
>> It seems xwiki use session token through URL(GET). The vulnerability test team suggest to use POST method instead GET.
>>
>> Is there any option to use POST method instead of GET method to transmit the session token information?
>
> It's not a really a all or nothing central place so we would need to
> know where exactly you have this issue to see if there is a way to fix
> it in a case by case basis.
>
>>
>>
>>
>> 4.Username retrieval with no verification
>>
>> When the user forget the username, the user can retrieve username with email address. However it is not sent to email but show in the site.
>>
>> The vulnerability test team think the hacker can get the username if they try many different combination of email.
>>
>> Is it possible xwiki only send the username by email instead of showing in the page ?
>
> Would be great if you could create an issue about that on
> http://jira.xwiki.org. Looks easy to fix, just need to discuss if we
> should do it or not. On my side I did not know we were displaying the
> user id in this page and I agree that it's probably not a good idea.
>
>>
>>
>>
>>
>> 5. Password Validation is weak
>>
>> It seems xwiki allow weak password to register new user.
>>
>> Is it possible to use strong password only when new user registered in xwiki?
>
> It's possible to add a lot of constraint in the registration form. See
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Appli….
>
>>
>>
>>
>> These are the all issue they addressed.
>>
>> Please let me know the answer.
>>
>> Thank you and have a good day
>>
>> Kwan Kim
>
>
>
> --
> Thomas Mortagne
Thanks for your report Kwan Kim :),
Adel Atallah
I am Kwan Kim who works for the Rogosin Institute (medical research company specialized for Kidney disease in New York)
Recently we tried to use xwiki as an our wiki server.
So we configured the xwiki server on Redhat, MySQL & Glassfish environment and ask vulnerability test team to test.
However they found several security issues.
And I am not a expert for the xwiki so I am not sure whether xwiki already has a solution to fix the issues or not.
That’s why I would like to ask you about the security features of xwiki.
This is the security problems which the vulnerability team addressed below:
1. Cross Site Scripting (XSS): Script insertion at Name Field in the registration form.
When new user register, there is first and last name field. thesis fields allow javascript code.
Is there any way we can put the some validation to prevent the javascript code ?
[cid:E6CD6E35-B5EA-48C1-86BD-525C5F1940F3@med.cornell.edu]
2. No controls for Account Creation
The vulnerability test team think it is too easy to create new account
Is there any way that new account need to get approval from admin user ?
3.Site discloses session tokens in multiple locations
It seems xwiki use session token through URL(GET). The vulnerability test team suggest to use POST method instead GET.
Is there any option to use POST method instead of GET method to transmit the session token information?
[cid:4EB11B1D-6F82-4E58-BA22-A828358F5F9F@med.cornell.edu]
4.Username retrieval with no verification
When the user forget the username, the user can retrieve username with email address. However it is not sent to email but show in the site.
The vulnerability test team think the hacker can get the username if they try many different combination of email.
Is it possible xwiki only send the username by email instead of showing in the page ?
[cid:7C406F30-67F3-4868-A874-1E9DF704AC75@med.cornell.edu]
5. Password Validation is weak
It seems xwiki allow weak password to register new user.
Is it possible to use strong password only when new user registered in xwiki?
[cid:38B73B7C-A420-4478-8BA0-A89E8897C1AC@med.cornell.edu]
These are the all issue they addressed.
Please let me know the answer.
Thank you and have a good day
Kwan Kim