Re: [xwiki-devs] [Proposal] Weblate as XWiki's translation platform

[Sergiu Dumitriu]

On 04/24/2018 09:44 AM, Clément Aubin wrote:
> On 04/23/2018 12:18 PM, Adel Atallah wrote:
>> Hello everyone,
> 
> Hi,
> 
> AFAICS Weblate looks nice, but haven't we looked at other alternatives ?
> 
> Here are some of them :
> 
> * http://jabylon.org/ (uses Java, so it might be easier to integrate)
> * http://zanata.org/
> * http://pootle.translatehouse.org/
> * https://pontoon.mozilla.org/

I've been quite happy with https://crowdin.com/ , which handles
ApplicationResources.properties very well, but isn't ideal for the .xml
translations. It's free for open source projects.

The problem with the .xml files is that apart from the translatable
content, which it handles well, it tries to commit the exact same XML
markup as in the "source" file, which doesn't really work for XWiki. As
a workaround, I just cat|sed the contents of the XML files and upload it
as a non-github-tracked resource. The alternative is to
rebase-interactive each pull request it creates to discard the commits
that try to re-format the XML files, but that gets tedious after a while.

> Also, I think that it has already been discussed, either on
> https://xwiki.markmail.org/search/?q=weblate or on IRC, but being able
> to use xwiki.org as an identity provider on our translation platform
> would be neat, so it could be something to look for in the possible
> solutions.
> 
>> As you may already know, we have thought about replacing the l10n platform
>> which is becoming too slow. Weblate seems to be a good replacement choice,
>> as it will able contributors to have their name in the commits and it has
>> every features needed to make translations.
>>
>> One problem is that XWiki doesn't use a standard method to process
>> translation files. We can solve that by creating some scripts to convert
>> XWiki translation files into one that Weblate can understand.
>>
>> A detailed solution can be found here :
>> http://design.xwiki.org/xwiki/bin/view/Proposal/WeblateasXWikistranslationplatform
> 
> We'll indeed need to convert our translation files to a more "standard"
> format, but I fear that using Python might decrease the maintainability
> of those scripts.
> 
> WDYT ?
> 
>> Feel free to discuss it by responding here or directly in the design page.
>>
>> Thanks,
>>  *Adel Atallah*
>> *Product developer intern*
>> adel.atal...@xwiki.com 
>> tel: +33 (0)6 12 96 35 06
>>
> 
> Thanks,
> Clément
> 


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

Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

By the way this is not only about XWiki Standard. We also need to
think about entry type in contrib extensions you know.

On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
 wrote:
> As I indicated it would be better if you could send other mail to
> discuss those pages separately (there is already one for the the
> themes) :)
>
> On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
>  wrote:
>> Dashboard.WebHome should be editable.
>> FlamingoThemes.* should be editable in order for users to set custom logos.
>> XWiki.DefaultSkin should be editable for the same logo reason.
>>
>> Thanks,
>> Caty
>>
>> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne 
>> wrote:
>>
>>> Hi devs,
>>>
>>> When dealing with extension pages protection we ended up with a very
>>> visible issue: EVERYONE customize the home page so it does not make
>>> much sense to warn every user trying to edit it that it's dangerous
>>> and might break the extensions.
>>>
>>> Since it's not the only use case 10.3 introduce the concept of XAR
>>> entry type which allow controlling a bit more edit/delete and upgrade
>>> behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+
>>> Module+Specifications#Hpackage.xml
>>> for more details.
>>>
>>> On component side it's possible to decide the default type of a page
>>> reference (that's where "Main.WebHome" type come from currently). It's
>>> also possible to override the upgrade behavior for a specific type or
>>> even a specific reference for more exotic use cases.
>>>
>>> So it's now possible to control the type you want for a page at XAR
>>> descriptor level. I already typed a few page, for example
>>> "Main.WebHome" is now of type "home" which means "it's OK to edit it
>>> and you should only upgrade it if no customization have been made".
>>>
>>> Cool home page is covered but we now entered a new era of endless
>>> debates to decide of what type some page should be and what other
>>> types to introduce :)
>>>
>>> We are not going to discuss all these in this mail so everyone with a
>>> doubt should start a discussion for a standard page (or a set of
>>> standard page which are obviously very similar like color themes).
>>>
>>> Currently, protected page produce a warning that you can force. The
>>> plan in 10.4 is to keep the warning only for advanced completely
>>> prevent basic user to modify protected pages by default and also allow
>>> configuring all that (indicate in your profile that you don't want to
>>> be bothered with that, override edit/delete right even for advanced
>>> users, etc.). But before that we need to make sure basic users are
>>> allowed to edit all the pages they are supposed to edit.
>>>
>>> Happy tuning :)
>>>
>>> --
>>> Thomas Mortagne
>>>
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne

[xwiki-devs] [XWiki Day] BFD#174

[Alex Cotiugă]

Hello devs,

This Thursday is BFD#174:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays

Our current status is:
* -49 bugs over 120 days (4 months), i.e. we need to close 49 bugs to have
created bugs # = closed bugs #
* -95 bugs over 365 days (1 year)
* -112 bugs over 500 days (between 1 and 2 years)
* -312 bugs over 1600 days (4.3 years)

See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352


Here's the BFD#174 dashboard to follow the progress during the day:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=14292

Happy Bug Fixing Day,
Alex

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Thomas Mortagne]

So it seems that 2) is currently leading with Ecaterina and Vincent.

Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
about delete ?).

Marius, does your proposal means you are more for 1) but with the
difference that the default color theme would be allowed for edit ?

Any other point of view input ?

On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
 wrote:
> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne 
> wrote:
>
>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
>> wrote:
>> > To give my opinion, I’m hesitating about 2 approaches:
>> >
>> > Approach 1: “standard"
>> > ==
>> >
>> > * We should have “Default Color Theme” be a copy from the Iceberg color
>> theme page. I think I’d prefer the copy to be done at runtime; for example
>> if the currently defined color theme page doesn’t exist when going to the
>> L > Themes admin page, create it by copying Iceberg. This provides a self
>> healing feature if the color theme page has been removed/doesn’t exist/etc.
>> >
>> > * Predefined color theme pages should be considered “standard” and a
>> warning message displayed if a user wants to edit them. BTW would be nice
>> to have a feature to have a customized message per “type”. For example for
>> color theme pages we would display a message saying that the user should
>> copy the page to customize it instead of editing it.
>> >
>> > * The Color Theme UI should also be improved a bit to have a “Customize”
>> button on color theme pages that would perform a copy to let the user
>> customize a theme.
>> >
>> > Approach 2: “demo"
>> > 
>> >
>> > * Consider all color themes to be demo content and once the user starts
>> modifying them don’t merge them anymore
>> > * When we want to provide modified color themes, introduce new theme
>> pages
>> > * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to
>> be the default CT.
>> >
>> > Analysis
>> > ===
>> >
>> > Approach 2 is more wiki style and simpler for sure. Users can use the
>> diff feature and the rollback feature if they want to go back to the
>> original versions.
>> >
>> > I think I’m leaning more towards 2 ATM.
>>
>> So you think delete is OK too, right ?
>>
>
> For me delete is ok too. IMO we should provide just a few themes by
> default, and the user should be able to uninstall and install what themes
> he wants (ideally he would be able to preview them live).
>
> I don't like the copying part very much. Users like to have a base to start
> from, but they also have history as a fallback.
>
> Also we rarely make changes to ColorThemes, especially since they are not
> very complex since they should contain only variables. Still it all depends
> on how well the Default Theme is tested initially.
>
> Thanks,
> Caty
>
>
>>
>> >
>> > Thanks
>> > -Vincent
>> >
>> >> On 25 Apr 2018, at 11:35, Vincent Massol  wrote:
>> >>
>> >> Is this a VOTE or a proposal or a brainstorming? I’m asking since
>> nobody has voted yet, not even Thomas (except if we consider that “prefer”
>> means +1 and “OK” means +0 ;)).
>> >>
>> >> From the answer it seems we might need a new VOTE since several new
>> points have been added to the discussion. I’m not able to VOTE right now.
>> >>
>> >> Thanks
>> >> -Vincent
>> >>
>> >>> On 23 Apr 2018, at 12:29, Thomas Mortagne 
>> wrote:
>> >>>
>> >>> Hi xwikiers,
>> >>>
>> >>> Following new XAR entry type mail here is a question about color
>> >>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
>> >>>
>> >>> 1) Standard stuff, if you want a custom color theme create a new one
>> >>> (would be nice to be able to copy a standard one and propose it when
>> >>> you try to edit a standard one).
>> >>>
>> >>> 2) Demo content, edit and delete it all you want and upgrade won't
>> >>> touch a customized theme to avoid surprises (background color changed
>> >>> a bit in the standard version which now collide with your logo)
>> >>>
>> >>> 3) Same as 2 but delete is bad (same as home page)
>> >>>
>> >>> WDYT ?
>> >>>
>> >>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
>> >>> example than standard material. Let's say -0 for 2).
>> >>>
>> >>> Thanks,
>> >>> --
>> >>> Thomas Mortagne
>> >>
>> >
>>
>>
>>
>> --
>> Thomas Mortagne
>>



-- 
Thomas Mortagne

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Ecaterina Moraru (Valica)]

On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne 
wrote:

> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
> wrote:
> > To give my opinion, I’m hesitating about 2 approaches:
> >
> > Approach 1: “standard"
> > ==
> >
> > * We should have “Default Color Theme” be a copy from the Iceberg color
> theme page. I think I’d prefer the copy to be done at runtime; for example
> if the currently defined color theme page doesn’t exist when going to the
> L > Themes admin page, create it by copying Iceberg. This provides a self
> healing feature if the color theme page has been removed/doesn’t exist/etc.
> >
> > * Predefined color theme pages should be considered “standard” and a
> warning message displayed if a user wants to edit them. BTW would be nice
> to have a feature to have a customized message per “type”. For example for
> color theme pages we would display a message saying that the user should
> copy the page to customize it instead of editing it.
> >
> > * The Color Theme UI should also be improved a bit to have a “Customize”
> button on color theme pages that would perform a copy to let the user
> customize a theme.
> >
> > Approach 2: “demo"
> > 
> >
> > * Consider all color themes to be demo content and once the user starts
> modifying them don’t merge them anymore
> > * When we want to provide modified color themes, introduce new theme
> pages
> > * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to
> be the default CT.
> >
> > Analysis
> > ===
> >
> > Approach 2 is more wiki style and simpler for sure. Users can use the
> diff feature and the rollback feature if they want to go back to the
> original versions.
> >
> > I think I’m leaning more towards 2 ATM.
>
> So you think delete is OK too, right ?
>

For me delete is ok too. IMO we should provide just a few themes by
default, and the user should be able to uninstall and install what themes
he wants (ideally he would be able to preview them live).

I don't like the copying part very much. Users like to have a base to start
from, but they also have history as a fallback.

Also we rarely make changes to ColorThemes, especially since they are not
very complex since they should contain only variables. Still it all depends
on how well the Default Theme is tested initially.

Thanks,
Caty


>
> >
> > Thanks
> > -Vincent
> >
> >> On 25 Apr 2018, at 11:35, Vincent Massol  wrote:
> >>
> >> Is this a VOTE or a proposal or a brainstorming? I’m asking since
> nobody has voted yet, not even Thomas (except if we consider that “prefer”
> means +1 and “OK” means +0 ;)).
> >>
> >> From the answer it seems we might need a new VOTE since several new
> points have been added to the discussion. I’m not able to VOTE right now.
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> On 23 Apr 2018, at 12:29, Thomas Mortagne 
> wrote:
> >>>
> >>> Hi xwikiers,
> >>>
> >>> Following new XAR entry type mail here is a question about color
> >>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> >>>
> >>> 1) Standard stuff, if you want a custom color theme create a new one
> >>> (would be nice to be able to copy a standard one and propose it when
> >>> you try to edit a standard one).
> >>>
> >>> 2) Demo content, edit and delete it all you want and upgrade won't
> >>> touch a customized theme to avoid surprises (background color changed
> >>> a bit in the standard version which now collide with your logo)
> >>>
> >>> 3) Same as 2 but delete is bad (same as home page)
> >>>
> >>> WDYT ?
> >>>
> >>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
> >>> example than standard material. Let's say -0 for 2).
> >>>
> >>> Thanks,
> >>> --
> >>> Thomas Mortagne
> >>
> >
>
>
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Thomas Mortagne]

On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol  wrote:
> To give my opinion, I’m hesitating about 2 approaches:
>
> Approach 1: “standard"
> ==
>
> * We should have “Default Color Theme” be a copy from the Iceberg color theme 
> page. I think I’d prefer the copy to be done at runtime; for example if the 
> currently defined color theme page doesn’t exist when going to the L > 
> Themes admin page, create it by copying Iceberg. This provides a self healing 
> feature if the color theme page has been removed/doesn’t exist/etc.
>
> * Predefined color theme pages should be considered “standard” and a warning 
> message displayed if a user wants to edit them. BTW would be nice to have a 
> feature to have a customized message per “type”. For example for color theme 
> pages we would display a message saying that the user should copy the page to 
> customize it instead of editing it.
>
> * The Color Theme UI should also be improved a bit to have a “Customize” 
> button on color theme pages that would perform a copy to let the user 
> customize a theme.
>
> Approach 2: “demo"
> 
>
> * Consider all color themes to be demo content and once the user starts 
> modifying them don’t merge them anymore
> * When we want to provide modified color themes, introduce new theme pages
> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be 
> the default CT.
>
> Analysis
> ===
>
> Approach 2 is more wiki style and simpler for sure. Users can use the diff 
> feature and the rollback feature if they want to go back to the original 
> versions.
>
> I think I’m leaning more towards 2 ATM.

So you think delete is OK too, right ?

>
> Thanks
> -Vincent
>
>> On 25 Apr 2018, at 11:35, Vincent Massol  wrote:
>>
>> Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has 
>> voted yet, not even Thomas (except if we consider that “prefer” means +1 and 
>> “OK” means +0 ;)).
>>
>> From the answer it seems we might need a new VOTE since several new points 
>> have been added to the discussion. I’m not able to VOTE right now.
>>
>> Thanks
>> -Vincent
>>
>>> On 23 Apr 2018, at 12:29, Thomas Mortagne  wrote:
>>>
>>> Hi xwikiers,
>>>
>>> Following new XAR entry type mail here is a question about color
>>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
>>>
>>> 1) Standard stuff, if you want a custom color theme create a new one
>>> (would be nice to be able to copy a standard one and propose it when
>>> you try to edit a standard one).
>>>
>>> 2) Demo content, edit and delete it all you want and upgrade won't
>>> touch a customized theme to avoid surprises (background color changed
>>> a bit in the standard version which now collide with your logo)
>>>
>>> 3) Same as 2 but delete is bad (same as home page)
>>>
>>> WDYT ?
>>>
>>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
>>> example than standard material. Let's say -0 for 2).
>>>
>>> Thanks,
>>> --
>>> Thomas Mortagne
>>
>



-- 
Thomas Mortagne

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Vincent Massol]

To give my opinion, I’m hesitating about 2 approaches:

Approach 1: “standard"
==

* We should have “Default Color Theme” be a copy from the Iceberg color theme 
page. I think I’d prefer the copy to be done at runtime; for example if the 
currently defined color theme page doesn’t exist when going to the L > Themes 
admin page, create it by copying Iceberg. This provides a self healing feature 
if the color theme page has been removed/doesn’t exist/etc.

* Predefined color theme pages should be considered “standard” and a warning 
message displayed if a user wants to edit them. BTW would be nice to have a 
feature to have a customized message per “type”. For example for color theme 
pages we would display a message saying that the user should copy the page to 
customize it instead of editing it.

* The Color Theme UI should also be improved a bit to have a “Customize” button 
on color theme pages that would perform a copy to let the user customize a 
theme.

Approach 2: “demo"


* Consider all color themes to be demo content and once the user starts 
modifying them don’t merge them anymore
* When we want to provide modified color themes, introduce new theme pages
* Don’t provide a “Default Color Theme” page. Directly set “Iceberg” to be the 
default CT.

Analysis
===

Approach 2 is more wiki style and simpler for sure. Users can use the diff 
feature and the rollback feature if they want to go back to the original 
versions.

I think I’m leaning more towards 2 ATM.

Thanks
-Vincent

> On 25 Apr 2018, at 11:35, Vincent Massol  wrote:
> 
> Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has 
> voted yet, not even Thomas (except if we consider that “prefer” means +1 and 
> “OK” means +0 ;)).
> 
> From the answer it seems we might need a new VOTE since several new points 
> have been added to the discussion. I’m not able to VOTE right now.
> 
> Thanks
> -Vincent
> 
>> On 23 Apr 2018, at 12:29, Thomas Mortagne  wrote:
>> 
>> Hi xwikiers,
>> 
>> Following new XAR entry type mail here is a question about color
>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
>> 
>> 1) Standard stuff, if you want a custom color theme create a new one
>> (would be nice to be able to copy a standard one and propose it when
>> you try to edit a standard one).
>> 
>> 2) Demo content, edit and delete it all you want and upgrade won't
>> touch a customized theme to avoid surprises (background color changed
>> a bit in the standard version which now collide with your logo)
>> 
>> 3) Same as 2 but delete is bad (same as home page)
>> 
>> WDYT ?
>> 
>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
>> example than standard material. Let's say -0 for 2).
>> 
>> Thanks,
>> -- 
>> Thomas Mortagne
> 

Re: [xwiki-devs] [Proposal] Weblate as XWiki's translation platform

[Adel Atallah]

Hi Vincent,

- What I mean by "pulling changes" is to update the git repository (e.g.
xwiki-platform) used by Weblate to find translations, and what I mean by
"committing changes" is to create a commit with the new translations made
by a user.

- When I wrote “same way as above”, I meant that the script should extract
the content of the XML file and then treat it like a regular Java
properties file (as it should in the previous case).

- The ".translation" directory doesn't have to (and shouldn't) be committed
in the git repos.

- AFAICS, you can't simply add a new file format to weblate as it uses
another project for translations (
http://docs.translatehouse.org/projects/translate-toolkit/en/latest/formats/index.html)
and this tool also uses converters.

- About your other idea, this is exactly what the scripts are performing
but without using any API and using weblate's hooks.

- As for the other features, I don't think any of the suggested tools are
able to handle deprecated keys and renaming. We could just exclude the
deprecated section of the generated translations files so it doesn't appear
on Weblate.

I know that having to do what I described is a bit hackish but I think that
if we want to use a dedicated tool to deal with translations, we will have
to create a converter. You can find a list of converter used by the
translate toolkit here
: 
http://docs.translatehouse.org/projects/translate-toolkit/en/latest/commands/index.html

.

Thanks for your reply,

 *Adel Atallah*
*Product developer intern*
adel.atal...@xwiki.com
tel: +33 (0)6 12 96 35 06

On Wed, Apr 25, 2018 at 10:47 AM, Vincent Massol  wrote:

>
>
> > On 24 Apr 2018, at 15:44, Clément Aubin  wrote:
> >
> > On 04/23/2018 12:18 PM, Adel Atallah wrote:
> >> Hello everyone,
> >
> > Hi,
> >
> > AFAICS Weblate looks nice, but haven't we looked at other alternatives ?
> >
> > Here are some of them :
> >
> > * http://jabylon.org/ (uses Java, so it might be easier to integrate)
> > * http://zanata.org/
> > * http://pootle.translatehouse.org/
> > * https://pontoon.mozilla.org/
> >
> > Also, I think that it has already been discussed, either on
> > https://xwiki.markmail.org/search/?q=weblate or on IRC, but being able
> > to use xwiki.org as an identity provider on our translation platform
> > would be neat, so it could be something to look for in the possible
> > solutions.
> >
> >> As you may already know, we have thought about replacing the l10n
> platform
> >> which is becoming too slow. Weblate seems to be a good replacement
> choice,
> >> as it will able contributors to have their name in the commits and it
> has
> >> every features needed to make translations.
> >>
> >> One problem is that XWiki doesn't use a standard method to process
> >> translation files. We can solve that by creating some scripts to convert
> >> XWiki translation files into one that Weblate can understand.
> >>
> >> A detailed solution can be found here :
> >> http://design.xwiki.org/xwiki/bin/view/Proposal/
> WeblateasXWikistranslationplatform
> >
> > We'll indeed need to convert our translation files to a more "standard"
> > format, but I fear that using Python might decrease the maintainability
> > of those scripts.
>
> - You said "Weblate is able to run scripts after pulling changes from the
> git repository and before committing changes.”. I don’t understand this
> sentence. You mean to sync files that are located in our Git repos to
> weblate (git —> weblate)? When you say “committing changes” you mean
> loading changes from git and inside weblate?
>
> - You said "XML files with properties as content will be treated the same
> way as above”. I couldn’t find what you meant by “same way as above”.
> Certainly you’ll need to generate some properties file out of the XML file,
> no?
>
> - Globally I find what you describe very complex and a bit hackish.
> Especially the part about having some “.translation” directory which I
> assume you’ll want to commit in our git repos?
>
> - Isn’t it possible to add some new file format inside weblate instead so
> that it understands properties inside XML files, etc.?
>
> - Another idea: using weblate’s REST APIs to push/pull from weblate, using
> github web hooks to perform conversions:
> — when a change is pushed to a translation file in github, run a script to
> import it inside weblate using weblate’s REST API
> — when a change is done inside weblate and a PR is sent to our repos by
> weblate, run a script to convert the content to the proper format and
> modify the PR accordingly
>
> Even that sounds complex IMO. Being able to teach weblate about our format
> would seem the simplest. If we could do this we could even send weblate a
> PR to support our format natively.
>
> You also need to handle deprecated keys, ability to rename/move a key and
> all its translations, etc.
>

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Vincent Massol]

Is this a VOTE or a proposal or a brainstorming? I’m asking since nobody has 
voted yet, not even Thomas (except if we consider that “prefer” means +1 and 
“OK” means +0 ;)).

From the answer it seems we might need a new VOTE since several new points have 
been added to the discussion. I’m not able to VOTE right now.

Thanks
-Vincent

> On 23 Apr 2018, at 12:29, Thomas Mortagne  wrote:
> 
> Hi xwikiers,
> 
> Following new XAR entry type mail here is a question about color
> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> 
> 1) Standard stuff, if you want a custom color theme create a new one
> (would be nice to be able to copy a standard one and propose it when
> you try to edit a standard one).
> 
> 2) Demo content, edit and delete it all you want and upgrade won't
> touch a customized theme to avoid surprises (background color changed
> a bit in the standard version which now collide with your logo)
> 
> 3) Same as 2 but delete is bad (same as home page)
> 
> WDYT ?
> 
> I'm think I prefer 1) but I'm OK with 3) if other think it's more
> example than standard material. Let's say -0 for 2).
> 
> Thanks,
> -- 
> Thomas Mortagne

Re: [xwiki-devs] [Proposal] Weblate as XWiki's translation platform

[Vincent Massol]

> On 24 Apr 2018, at 15:44, Clément Aubin  wrote:
> 
> On 04/23/2018 12:18 PM, Adel Atallah wrote:
>> Hello everyone,
> 
> Hi,
> 
> AFAICS Weblate looks nice, but haven't we looked at other alternatives ?
> 
> Here are some of them :
> 
> * http://jabylon.org/ (uses Java, so it might be easier to integrate)
> * http://zanata.org/
> * http://pootle.translatehouse.org/
> * https://pontoon.mozilla.org/
> 
> Also, I think that it has already been discussed, either on
> https://xwiki.markmail.org/search/?q=weblate or on IRC, but being able
> to use xwiki.org as an identity provider on our translation platform
> would be neat, so it could be something to look for in the possible
> solutions.
> 
>> As you may already know, we have thought about replacing the l10n platform
>> which is becoming too slow. Weblate seems to be a good replacement choice,
>> as it will able contributors to have their name in the commits and it has
>> every features needed to make translations.
>> 
>> One problem is that XWiki doesn't use a standard method to process
>> translation files. We can solve that by creating some scripts to convert
>> XWiki translation files into one that Weblate can understand.
>> 
>> A detailed solution can be found here :
>> http://design.xwiki.org/xwiki/bin/view/Proposal/WeblateasXWikistranslationplatform
> 
> We'll indeed need to convert our translation files to a more "standard"
> format, but I fear that using Python might decrease the maintainability
> of those scripts.

- You said "Weblate is able to run scripts after pulling changes from the git 
repository and before committing changes.”. I don’t understand this sentence. 
You mean to sync files that are located in our Git repos to weblate (git —> 
weblate)? When you say “committing changes” you mean loading changes from git 
and inside weblate?

- You said "XML files with properties as content will be treated the same way 
as above”. I couldn’t find what you meant by “same way as above”.  Certainly 
you’ll need to generate some properties file out of the XML file, no?

- Globally I find what you describe very complex and a bit hackish. Especially 
the part about having some “.translation” directory which I assume you’ll want 
to commit in our git repos?

- Isn’t it possible to add some new file format inside weblate instead so that 
it understands properties inside XML files, etc.?

- Another idea: using weblate’s REST APIs to push/pull from weblate, using 
github web hooks to perform conversions:
— when a change is pushed to a translation file in github, run a script to 
import it inside weblate using weblate’s REST API
— when a change is done inside weblate and a PR is sent to our repos by 
weblate, run a script to convert the content to the proper format and modify 
the PR accordingly

Even that sounds complex IMO. Being able to teach weblate about our format 
would seem the simplest. If we could do this we could even send weblate a PR to 
support our format natively.

You also need to handle deprecated keys, ability to rename/move a key and all 
its translations, etc.

Thanks
-Vincent

> 
> WDYT ?
> 
>> Feel free to discuss it by responding here or directly in the design page.
>> 
>> Thanks,
>>  *Adel Atallah*
>> *Product developer intern*
>> adel.atal...@xwiki.com 
>> tel: +33 (0)6 12 96 35 06
>> 
> 
> Thanks,
> Clément