- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [VOTE] New Translation property naming rules
by vincent＠massol.net 05 Mar '15

05 Mar '15

Hi devs, At the moment the VOTED rule for naming our translation properties is the one defined at http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… Back in 2012 Sergiu started drafting an extended "L10N Conventions” document for best practices around writing translation properties at http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions Sergiu sent this a proposal in this mail thread: http://markmail.org/message/ofl23yorvxsqhn4x When Sergiu did this he didn’t realize we already had a VOTED rule for naming our translation properties and his proposal was in conflit with that. However, in this mail thread, several developers mentioned that even though they votes the previous naming rules they didn’t fully like it and preferred the one Sergiu was proposing. Several suggestion for improvements were also proposed. It was suggested in that thread (and Sergiu agreed) that he should resend a VOTE to change those established rules. Apparently he didn’t get the time/will to do it since I couldn’t find such a mail. In addition several developers are apparently not following the current rules (BAD! :)). For example in the xwiki-platform-icon-ui module, the Translations.xml page has the following which is NOT following the current rules: platform.icon.picker.preview=Preview with: platform.icon.picker.loading=Loading And most translation keys found in contrib apps at http://l10n.xwiki.org/xwiki/bin/view/Contrib/WebHome are also not following these rules (although we don’t enforce anything for contrib projects, when they are coded by devs from the XWiki dev team or by known contributors, it would be a good thing to follow the same rule, especially as, in the future, we want to provide a path to move from contrib sandbox to contrib extensions). For example I see the following type of naming: “polls.vote.instructions.single”. Thus, with this email I’d like to try agreeing on a new naming format and conventions. I propose to VOTE for making http://dev.xwiki.org/xwiki/bin/view/Drafts/L10N+Conventions our official practice with the following change for the property naming part: " Keys should have the following format: ##[module]*[.section]*.element[.part]*##, where: * ##module## is the name of the module or application being translated, like ##blog##, ##faq##, ##statistics##… Since a module can have submodules, there can be several module names. For example the SOLR Search UI is located in ##xwiki-platform-search/xwiki-platform-solr/xwiki-platform-solr-ui## and would have keys starting with ##search.solr.##. * zero, one or more ##section## parts that further refine the location of the string being translated; for example, a key starting with ##theme.colors.wizard.## refers to a text located in the //wizard// for the //color// part of the //theme// application (currently there are only color themes, but in the future we might add icon themes, layout themes, and so on), ##macro.python.parameter.## refers to //parameters// of the //python// //macro//, while a key starting with ##userdirectory.## belongs to the main and only section of the //user directory// application * ##element## identifies the main element being translated, but such an element could have several related parts. * ##part## identifies a text related to a main element, such as the ##label## that describes an input, the ##placeholder## found inside that input, the ##tooltip## that appears when hovering that input, the ##hint## that is displayed before the field and provides additional details about what it, the ##error.empty## or ##error.invalidFormat## displayed when there are validation errors, and so on Individual parts of the key should use **camelCase** if more than one word is needed to identify the element. “ Note that I’ve removed the ##product## part from Sergiu’s proposal (the reasoning is here: http://markmail.org/message/ocijlegslw45yedu) In short this makes it simpler to move apps around without breaking the translation keys. Of course it reduces the namespace and increases likelihood of translation clashes with user-provided extensions but I don’t think it’s going to be a problem and user-provided extensions should have a unique app name anyway. I would also point to http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTransla… for the deprecation part. The big question is what to do with existing translations and the only answer I have so far is: * Use the new rules when adding new translation keys (after, and if, it’s voted) * Don’t touch existing keys for now (since that would loose all translations) but implement the following first, and once it’s done, refactor existing translations over time: ** Add support for a deprecation section in Translations.xml’s content, honoured by l10n in the same way that we do it for ApplicationResources.properties ** Add the new key ** Move the old key to the deprecation section (in ApplicationResources.properties or in Translations.xml) ** Make the old key point to the new key, using a special syntax. For example: my.old.deprecated.key = @{new.shiny.key} Here’s my +1 Thanks -Vincent

6 10

[xwiki-devs] [Proposal] Location of translation properties
by vincent＠massol.net 05 Mar '15

05 Mar '15

Hi Devs, Even though we don’t have listed on http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices I believe the following has already been agreed but I’d like to add it there so I’m sending it as a proposal. So I propose that: * Any java code requiring translation should put them in an ApplicationResources.properties file at the root of the JAR (not the global ApplicationResources.properties in oldcore!) * Any wiki page requiring translations should put them in a Translations page in the space for the app. Special case: * For Macro UI modules (ie containing only wiki macros), we put them in the Macros space and in this case we should use a Macros.XXXTranslations page for each module. We’ll need to decide what we want to do in the future. Also, even if some existing module is wrongly using the ApplicationResources.properties in oldcore (for example), we should still follow the rules above and start doing it in the new way. WDYT? Thanks -Vincent

5 8

[xwiki-devs] [ANN] XWiki 7.0 Milestone 2 released
by Marius Dumitru Florea 04 Mar '15

04 Mar '15

The XWiki development team is proud to announce the availability of XWiki 7.0 Milestone 2. This release comes with a simplified Wiki Creation Wizard and the ability to organize and filter extensions by category in the Extension Repository. The install date and the user that performed the install are now available in the extension details, and the extensions that were installed explicitly are now displayed distinctly. A stronger confirmation should prevent users from deleting wikis by mistake from now on. The developers may be interested by the API improvements made to the Mail Sender and Extension Manager modules. 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/ReleaseNotesXWiki70M2 Thanks -The XWiki dev team

1 0

[xwiki-devs] [myxwiki] XWiki Enterprise 6.4.2 Upgrade
by Thomas Mortagne 03 Mar '15

03 Mar '15

Hi everyone, myxwiki.org has been upgraded to XE 6.4.2. If you own a wiki hosted there you should have a look at the release notes for this version at: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ You should automatically get an upgrade wizard for your wiki when you login as admin. For more details see the upgrade guide available at : http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Upgrade#HUpgradingwikid… To be notified of the myxwiki.org server upgrade you can follow myxwiki on twitter: http://twitter.com/myxwiki Thanks, -XWiki Community

1 0

[xwiki-devs] [GSoC] XWiki was not selected for GSoC this year
by Eduard Moraru 02 Mar '15

02 Mar '15

Hi, "Thank you for submitting XWiki's application to Google Summer of Code 2015. Unfortunately, we were unable to accept your organization's application at this time. Every year we receive many more applications than we are able to accommodate, and we would encourage you to reapply for future instances of the program." Unfortunately, we did not make it this year. However, if any student is interested in doing any of our proposed projects outside of GSoC, we can still provide guiding and support all the way, as long as they are willing to learn ;) Better luck next year, Eduard

1 0

[xwiki-devs] Fwd: [Reminder] Using superadmin author for pages not imported at runtime
by Marius Dumitru Florea 02 Mar '15

02 Mar '15

---------- Forwarded message ---------- From: Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> Date: Mon, Mar 2, 2015 at 12:32 PM Subject: Re: [xwiki-devs] [Reminder] Using superadmin author for pages not imported at runtime To: "vincent(a)massol.net" <vincent(a)massol.net> On Mon, Mar 2, 2015 at 12:08 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: > > > On 2 Mar 2015 at 10:34:03, Marius Dumitru Florea > ([email protected](mailto:[email protected])) > wrote: > >> I had forgotten about this vote. I'm not against using a special >> 'system' user, but as Denis pointed out, we also have to think about >> how this will be displayed in the UI (including localization). Until >> we have this I'm -0. > > Don’t forget that we’re already using that for all xclasses initialized by > java code. Those are hidden documents that you rarely get to see. It's still not nice but at least it's not very visible. While this "Installed by superadmin." will be visible whenever you look at the details of a XAR extension installed by default (e.g. the Blog application). > I don’t see why “superadmin” is not a good display name for now (till we > introduce another System user). Will a non-English speaker understand it? And even for those that understand English it's gibberish, a technical identifier. Thanks, Marius > > Thanks > -Vincent > >> Thanks, >> Marius >> >> On Mon, Mar 2, 2015 at 11:17 AM, Denis Gervalle wrote: >> > Hi Vincent, >> > >> > Of course, I still agree with the above vote, but I think we should also >> > improve the display of the superadmin user, currently it does not have >> > any >> > display name, and IMO it will look odd to have more and more pages >> > created >> > and authored by "superadmin". I have actually not a clear idea about the >> > right name, but it should be self explanatory, and superadmin is not in >> > my >> > opinion. I remember we talk about "System", which is a bit better, but >> > we >> > may still find something better. "XWiki System",... please make cleverer >> > proposal :) >> > WDYT ? >> > >> > >> > On Mon, Mar 2, 2015 at 8:56 AM, vincent(a)massol.net >> > wrote: >> > >> >> Hi devs, >> >> >> >> We already had a VOTE about this in the past ( >> >> http://markmail.org/message/p5cvswxtrnm54i3m) where we agreed to use >> >> the >> >> superadmin user. >> >> >> >> I see it’s been done only for xclass pages created by XWiki so far. >> >> >> >> According to the VOTE we should also do that for pages imported by the >> >> packager plugin too. >> >> >> >> See also the comments at >> >> >> >> >> >> https://github.com/xwiki/xwiki-platform/commit/5d5020052983d1a4de255104f8a8… >> >> >> >> I hope devs still agree about that vote :) And for those who didn’t >> >> VOTE >> >> at the time, please reply to this mail. >> >> >> >> Note: I don’t find it normal that the packager plugin would use the >> >> Admin >> >> user since it’s a user that isn’t necessarily present in the wiki >> >> whereas >> >> the superadmin always is. >> >> >> >> Thanks >> >> -Vincent >> >>

1 0

[xwiki-devs] [Reminder] Using superadmin author for pages not imported at runtime
by vincent＠massol.net 02 Mar '15

02 Mar '15

Hi devs, We already had a VOTE about this in the past (http://markmail.org/message/p5cvswxtrnm54i3m) where we agreed to use the superadmin user. I see it’s been done only for xclass pages created by XWiki so far. According to the VOTE we should also do that for pages imported by the packager plugin too. See also the comments at https://github.com/xwiki/xwiki-platform/commit/5d5020052983d1a4de255104f8a8… I hope devs still agree about that vote :) And for those who didn’t VOTE at the time, please reply to this mail. Note: I don’t find it normal that the packager plugin would use the Admin user since it’s a user that isn’t necessarily present in the wiki whereas the superadmin always is. Thanks -Vincent

3 5

[xwiki-devs] [Contrib] Request repository for "RFC" Application
by Fabio Mancinelli 27 Feb '15

27 Feb '15

Hi all, I would like to create a repository on xwiki-contrib for a little application I wrote. Basically it allows to manage a document base like the one about IETF's RFCs (http://www.ietf.org/rfc.html) Name: application-rfc Tools: NONE Thanks, Fabio P.S.: I think I can create the repo by myself, so this mail was just to announce the repo creation.

2 2

[xwiki-devs] [XWiki Day] BFD#81
by Eduard Moraru 27 Feb '15

27 Feb '15

Hi devs, Today is BFD#81: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 68 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R… Here's the BFD#81 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13098 Thanks and enjoy your bug fixing day! -Eduard

1 1

[xwiki-devs] Can I delete translations marked as "Dead"?
by Valdis Vītoliņš 26 Feb '15

26 Feb '15

Can I delete translations marked as "Dead"? When I need to "refactor" some common term, I find it in "Dead" translations also, which, if not updated, appears as unwanted search results. Valdis

2 3