Hi everyone !
So, recently I have been dealing with a module that uses two kind of
translation strings.
- "Static" translations : the title of a block, a xHint, … the
translation key itself is not meant to be changed over time.
- "Dynamic" translations : things like :
- mymodule.component.<componentId>.name
- mymodule.component.<componentId>.description
Those are translation strings that depend on a parameter (here
componentId) that can be part of a list.
If you want a better in-context example, check out this gist :
https://gist.github.com/aubincleme/19edb249082185deedc8ec36fe354d42
Currently, we don’t have a lot of best practices regarding the
translation keys (see the doc :
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla…),
so it may b nice to think about improving them.
Here are some proposals :
* For translation keys used for a livetable, we could use the following
: <prefix>.<liveTableId>Table.<columnName> or
<prefix>.table.<columnName> if the livetable doesn’t have a specific id.
* If we deal with "dynamic" translation keys, it would be nice to mark
them as different from the others with an underscore (_) prefix, or a
specific keyword.
WDYT ?
Thanks,
Clément
Hi devs,
Let’s do our first ProgrammingRights-Fixing Day. The goal is to modify pages part of XWiki Standard that require PR so that they don’t require PR anymore (for example by adding new APIs or using other APIs).
Here’s a list of pages that currently require PR (there are probably more):
* XWiki.DeletedDocumentsJSON
* AppWithinMinutes.DynamicMessageTool
* AnnotationCode.Style
* XWiki.DeletedDocuments
* AppWithinMinutes.LiveTableEditSheet
* AppWithinMinutes.ClassEditSheet
* XWiki.DeletedAttachments
* Main.Activity
* AnnotationCode.Script
(see http://jira.xwiki.org/browse/XWIKI-10446?focusedCommentId=83579&page=com.at… )
I suggest that we each mention which page we’re handling to avoid duplicating work.
Let’s try it! I have no idea what we’ll succeed in doing or not but we need to try :)
Thanks
-Vincent
Hi devs,
Here’s a proposal for XWiki 9.8 (1 month):
Dates
=====
* 9.8RC1: 18th of Sep 2017
* 9.8: 25th of Sep 2017
Sure
====
Regressions (highest importance):
* Put back the ability to import from office in CKEditor (as we had in the GWT editor) - Marius
Some leftovers from previous roadmaps to finish:
* Livetable improvements - Marius
** Implement bulk actions on livetable items
** Allow List of Users filtering also by entering first and last name, not just the user id
** Displaying a livetable list filter for a non-static list field is not scalable
** Support LiveTable text filtering on DBListclass columns
* Notifications - Continue work - Guillaume
** Finish replacing the Watchlist
** Replace the Activity Stream
** Add notifications for recommended apps
New:
* XWIKI-14605: REST resource installed as extension is broken when upgrading/uninstalling a JAR from the same namespace or root namespace - Thomas
Other:
* Work on restructuring xwiki.org on several aspects - Vincent + Caty
** Remove XWiki Enterprise and mention the Standard flavor instead
** Improve the navigation by adding a navigation panel on the left and reorg pages as nested pages where it makes sense
** Small improvements to the skin to make it simpler for a website
If time permits
============
* Fix the move issue: http://jira.xwiki.org/browse/XWIKI-14626
* Administration: Default values
** {{jira url="https://jira.xwiki.org" style="enum"}}XWIKI-14157{{/jira}} Display the default and inherited values in the Administration
** {{jira url="https://jira.xwiki.org" style="enum"}}XWIKI-9663{{/jira}} Show default value for date format in administration
* XWIKI-14162: Save button more visible. Position Save buttons on a fixed-bottom area. (continue from Pierre's PR)
* Improve XWiki Upgrades
** Display a notification when there’s a newer version available
** XWIKI-14377 Warnings when editing extension pages (same as for delete)
* Multipage tour feature
* Add an {{attachments}} macro
* Performance work
** Finish stuff to make filesystem attachment/history content the default (automatic migration, broken deleted attachments UI, etc.)
Let me know if anyone sees any issue with this and if other devs/contributors want to contribute something for 9.8!
Thanks
-Vincent
Greetings everyone!
I’m delighted to announce the first stable public release of the Dokuwiki importer, completing my GSOC project.
This importer can now:
> Support all supported archives from apache compress as both File and streaming input.
> Can import user data, document revision, and also attachments.
> Using the syntax parser from M2, it can convert the dokuwiki syntax to xwiki/2.1 syntax strings.
This can be downloaded from the extension page here: http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/ <http://extensions.xwiki.org/xwiki/bin/view/Extension/DokuWiki/>
Note: The syntax parser can also be used separately to parse dokuwiki syntax.
Suggestions/bugs are welcome!
Thanks!
Shubham Jain
Hi devs,
We've had several complaints from users about the Navigation Panel. The 3 big needs that I’ve heard are:
1) Semi-automated by having the ability to blacklist items
2) Better performance ("It’s slow to load and reloads every time you navigate to a new page”)
3) Ability to sort entries
See for ex:
* https://forum.xwiki.org/t/your-xwiki-usability-pain-points/440/11
* https://jira.xwiki.org/browse/XWIKI-12895
Point 1
======
That Panel is critical since it’s what users see the most (without navigating anywhere) and it’s important that users be able to customize it (while keeping the automated aspect, e.g. adding a new page should add it to the tree by default as it’s done now).
Marius mentioned that adding blacklisting doesn’t make sense because we would then have different behaviors between the Navigation Panel and:
• the breadcrumb trees
• the page index tree
• the location picker tree used on create/copy/rename page
• the location picker tree used by the CKEditor link and image dialogs
• anywhere we use a tree in XWiki default user interface
However I don’t fully agree about this. If you check the Applications Panel, it’s not listing all Apps that exist. It’s only listing Apps that the admin want his/her users to see by default. To see all apps there’s the App Index. Similarly the Navigation Panel on the left should be listing what the admin wants his/her users to see, and going to the Page Index should list all pages.
In short I really believe we need to allow customizing the panel with an Admin UI that allows to blacklist some nodes).
Does anyone see a better idea to fulfill our user’s needs?
Point 2
======
The main answer I see is to implement the doc title cache so that we don’t have to load documents.
Do you see anything else?
Point 3
======
I think this is kind of already implemented with “showDocumentTitle”, right?
Thanks
-Vincent
Hi GSOC students,
This is a reminder that there’s a deadline approaching soon:
"August 21-29: Students submit their work product (code) and a final evaluation of their Mentor”
On my side, I’m mentoring 2 projects:
* The Glossary Application project. Unfortunately this one failed the first review since not enough work was done. However Sarthak mentioned to me that he wanted to continue but he probably lost faith since I haven’t seen any work done. Sarthak, could you confirm that you dropped the topic altogether?
* The RedPen integration. There’s been several commits done and several status emails sent but it seems it’s lagging behind quite substantially since we’ve yet to see any working prototype. Desheng, it’s really important that you release ASAP a first working version on extensions.xwiki.org (that’s a condition of success) that we can try and install in our own XWiki instances.
Thanks
-Vincent
Hi devs,
We have several pages requiring PR and we’re not doing much about them.
This is a major pain, for example on myxwiki.org where, every time some admin update their wikis they break features. It’s not showing XWiki in good light neither.
I’ve found at least those pages requiring PR:
* XWiki.AllAttachmentsResults
* XWiki.DeletedDocumentsJSON
* AppWithinMinutes.DynamicMessageTool
* AnnotationCode.Style
* XWiki.DeletedDocuments
* AppWithinMinutes.LiveTableEditSheet
* AppWithinMinutes.ClassEditSheet
* XWiki.DeletedAttachments
* Main.Activity
* AnnotationCode.Script
(see http://jira.xwiki.org/browse/XWIKI-10446?focusedCommentId=83579&page=com.at… )
And FTR we keep adding more over time. For example in 2012, AWM introduced a PR: https://github.com/xwiki/xwiki-platform/commit/ae09194f83b9fe1f75778e0a2501…
I’d like to propose to do a PR-fixing day for the next non-BFD day, i.e. in 2 weeks.
WDYT?
Thanks
-Vincent
Hello XWiki team!
I just write to brag a bit about *Extension Repository Connector - NPM*
that I created in 3rd phase of GSoC ;)
You can read about it here:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository…
and
test it if you wish (there's an example to follow).
As before - any feedback highly appreciated :)
Have a nice day!
Best,
Krzysztof