Re: [kde-doc-english] Is asciidoc for us?

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
> 
> Back to the topic.
> Can anyone share opinion about the gitbook toolkit built on top of
> nodejs/asciidoc?
> 
> https://github.com/GitbookIO/gitbook
> 
> Things become more interesting it seems.
> 

Can you define shared entities with asciidoc?


Ciao
-- 
Luigi

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kexi, kdb, kproperty, kreport ready to translate

[Luigi Toscano]

Il 13 settembre 2016 00:53:44 CEST, Jaroslaw Staniek  ha 
scritto:
>Hi Luigi,
>kexi, kdb, kproperty, kreport are ready to translate, string freeze is
>on.
>
>
>PS: The releaseme tool gives no translations for Kexi (so tarballs I'll
>upload soon won't include translation files).
>kdb, kproperty, kreport tarballs include them.

I can only tell you again to talk with Harald; I could not check how releaseme 
works.
Or please use create_tarball_kf5 (see the example config) in the meantime.

>I am wondering if this is because
>repo-metadata/projects/calligra/kexi/metadata.yaml contains this:
>
>projectpath: calligra/kexi
>
>.. while the messages are still in calligra/?
>I am experiencing the same issue is with Krita but maybe that's not
>noticed
>only because the Krita Team does not seem to use releaseme for
>packaging.
>
>Another reason for having a kexi/ subdir would be: the .po files from
>various apps and plugins are too a bit too mixed within
>messages/calligra/
>so maybe some hierarchy would be good?

No, no, the structure of translation files has nothing to do with it. Proof: 
the existing tarballs of other projects.

-- 
Luigi

Re: Kexi 3.0 release is coming

[Luigi Toscano]

On Monday, 3 October 2016 12:02:14 CEST Jaroslaw Staniek wrote:
> Hi,
> We're close to the 3.0 release. I plan to create tarballs today.
> 
> Maintenance 3.0 branches have been created for Kexi projects
> (kexi/kdb/kproperty/kreport git) already.

We should finalize the move of the libraries outside of playground (which 
requires anyway passing through kdereview). We don't usually track stable 
branches of translations for playground modules (if it has releases, it's not 
playground).

-- 
Luigi

Re: Kexi 3.0 release is coming

[Luigi Toscano]

On Monday, 3 October 2016 12:14:21 CEST Jaroslaw Staniek wrote:
> On 3 October 2016 at 12:06, Luigi Toscano  wrote:
> > On Monday, 3 October 2016 12:02:14 CEST Jaroslaw Staniek wrote:
> > > Hi,
> > > We're close to the 3.0 release. I plan to create tarballs today.
> > > 
> > > Maintenance 3.0 branches have been created for Kexi projects
> > > (kexi/kdb/kproperty/kreport git) already.
> > 
> > We should finalize the move of the libraries outside of playground (which
> > requires anyway passing through kdereview). We don't usually track stable
> > branches of translations for playground modules (if it has releases, it's
> > not
> > playground).
> 
> ​Good,
> ​I remember I had a review like this when we had some time to discuss:
> https://phabricator.kde.org/D2659.
> I see no points against the move, just you may remember we were not really
> sure the move is good idea at the moment or needed:
> https://phabricator.kde.org/D2659#49459

I did not wrote that the move is not needed. I was commenting about the final 
destination.
If we put aside the destination, moving is required as "playground" and 
"stable branches" don't mix according our rules.

The step about "moving to kdereview" is not new and it is the usual rule that 
should (have) happen(ed) like in other similar cases, again regardless of the 
destination.

> Would you (or anyone else) be able to assist me in the move so we're ready
> for the release as planned? I did not allocate any resources for exactly
> this task today...

You can release for the current, but we can't create the translation branches 
for the stable branch until this is settled. So if you want to release, I 
would say (but I'm not part of release-team, which is not in CC either), 
release today but then allocate the time to move stuff around.

-- 
Luigi

Re: Phabricator: All repositories registered - upcoming workflow changes

[Luigi Toscano]

Ben Cooksley ha scritto:
> On Tue, Jan 31, 2017 at 11:36 PM, René J.V. Bertin  
> wrote:
>> On Sunday January 29 2017 08:32:21 Ben Cooksley wrote:
>>
>> Hi,
> 
> Hi Rene,
> 
>>
>> >From this point forward, communities should be moving away from
>>> Reviewboard to Phabricator for conducting code review. Sysadmin will
>>> be announcing a timeline for the shutdown of Reviewboard in the near
>>> future.
>>
>> I hope that shutdown doesn't mean complete disconnect; it would probably be 
>> a loss of as-yet unknown importance if all code reviews become unavailable.
>>
>> I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but 
>> RB had its advantages too which could be why it's still being used (quite a 
>> lot, as far as I can see) and hasn't been integrated with KDE's own IDE yet.
> 
> It will be a complete shutdown of Reviewboard - we'll be archiving it
> in the event for some reason it becomes necessary to access the data
> it stores.

Isn't it a way to change the site in static website and keep it alive?
Checking the history of a review can tell a lot. Also for discarded reviews.

> 
> In most cases mailing lists should have the history of reviews in
> their archives, so those will continue to be accessible through list
> archives in the long run.

I think we should ensure to have the archives on mail.kde.org if this is the 
case.


-- 
Luigi

Re: Phabricator: All repositories registered - upcoming workflow changes

[Luigi Toscano]

On Wednesday, 1 February 2017 11:52:01 CET Alexander Zhigalin wrote:
> Completely agreeing with Rene, Luigi and Milian.
> All this sounds very sad to me.
> Phabricator is indeed very powerful and better for management stuff.
> But Differential is not even merely comparable to RB by ease of use, mail
> notifications, review immediateness and usage speed...

If you have concerns and blockers that prevents the usage of Phabricator, 
please add tickets to the "Phabricator" board on our instance:
https://phabricator.kde.org/project/view/68/

There is no discussion around the point that, if reviewboard is kept around, 
it would be in read only mode and phabricator will be the only way to submit 
patches. But we are trying to see if it is possible to keep the content 
online, as it is not rare to go and check the history of a review, and not 
only for 2 years.

-- 
Luigi

Re: Phabricator: All repositories registered - upcoming workflow changes

[Luigi Toscano]

On Wednesday, 1 February 2017 10:31:44 CET Francis Herne wrote:
> Sorry, forgot to reply-all and only sent to kdevelop-devel...
> 
> -
> 
> Hi,
> 
> First off, there's a lot of postponed, or at least possibly-useful,
> work on ReviewBoard which would be lost. Some of this is from newish
> contributors who might be discouraged - e.g. the author of
> https://git.reviewboard.kde.org/r/129589/ mentioned on IRC the other
> day that he's hoping to complete it at some point.


I think that we need some cleanup on the old reviews (Albert Astal Cid started 
some time ago) and more important strongly tell new users (and old users) to 
use Phabricator. I don't think that anyone wants to lose the work, but if a 
review has not been touched in a few months maybe it's time to see it is still 
interesting. 
If we start doing this now (or yesterday), the flow of new patches in 
reviewboard should decrease quickly.


> For already-committed work:
> 
> Even if the mail-archiving infrastructure was in a useful state, this
> would be inconvenient - there are more than a *thousand* REVIEW: tags in
> kdev* project commits, plus several comments with "see ".
> 
> Many mailing lists aren't logged at all, there's no internal
> search with only patchy Google indexing, and 'browsing' the archive
> means clicking through arbitrarily-grouped mails by date with minimal
> threading. That's not merely inconvenient, it's going to cause a
> catastrophic loss of information.

I agree as well that the review information should be kept online.

-- 
Luigi

Re: Phabricator: All repositories registered - upcoming workflow changes

[Luigi Toscano]

René J.V. Bertin ha scritto:
> On Thursday February 2 2017 21:50:38 Nicolás Alvarez wrote:
> 
>> You missed the point. This "bit rot" is not about disk damage but
>> about software incompatibility. ZFS doesn't help with that...
> 
> You mean diffs that no longer apply cleanly? In that case you missed our 
> point. Being able to consult intermediate versions of diffs, abandoned diffs 
> etc. is not to be able to apply them "as is". If there were no value in the 
> kind of code those diffs (can) contain we'd not be using git or git wouldn't 
> be preserving every single bit of history. 
> 
> 
> Oh well. This is just another expression of FOSS's biggest weakness. Every 
> project has this centre-of-the-universe tendency that apparently justifies 
> breaking things for large parts of the user base whenever the project feels 
> it's justified.

No one is breaking anything. We are working to try to collect the problems and
have them solved, and if you look around in the discussion it seems that a
simple mirroring is working. Also, someone else was checking on IRC how the
Reviewboard API works.

Please let's focus on the way to solve problems.

-- 
Luigi

Re: 3.0.1 RC1 of Kexi/KDb/KProperty/KReport released

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
> 
> 
> On 16 March 2017 at 23:01, Jonathan Riddell  > wrote:
> 
> kproperty no longer has translations
> 3.0.0 had kproperty-3.0.0/po/pt/kproperty_qt.po files, these are not
> in the 3.0.1 tar
> 
> 
> ​Yes that's because ​
>  
> ​the ​
> ​releaseme tool ​failed to give them to me, neither hacks that I usually use.
> As you can see I managed to do some tricks for other libs. and no idea what
> was the difference. Regular translations would come after the kdereview
> process is finished for the libs (that is: 3.1). If nobody tracks down the
> issues for the 3.0.x, 3.0.2 won't have translations or we can just ship 
> older translations.

Alternative: complete now the review process.

> Everything is (poorly) reported to sysadmins and the authors of releaseme.

Alternative: try create_tarballs_kf5.


-- 
Luigi

Re: KEXI, KDb, KProperty, KReport 3.1 ready to translate

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
> Dear All,
> I'd like to declare string freeze for 4 projects: KEXI, KDb,
> KProperty, KReport version 3.1.
> 
> Beta would be announced on Jan 29th.
> Upload of stable is planned for Feb 22, 2018 so there is one month for
> testing messages and translating.
> Translating of docs is not recommended, it needs major update.

Are you going to release from master, or are you going to create a 3.0 branch
and we should copy the translations?

Ciao
-- 
Luigi

Re: KEXI, KDb, KProperty, KReport 3.1 ready to translate

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
> On 19 January 2018 at 19:13, Jaroslaw Staniek  wrote:
>> On 19 January 2018 at 19:03, Luigi Toscano  wrote:
> 
>>> Are you going to release from master, or are you going to create a 3.0 
>>> branch
>>> and we should copy the translations?
>>
>> 3.1 branch will be ready for stable 3.1.x releases today.
> 
> Update. All 4 repos now have 3.1 branches and 3.0.94 tags.
> This time releaseme tools worked well, translations magically found in
> extragear-libs :)
> Kudos for that.

Were they taken from the right branch? If they were taken from the existing
stable branch, 3.0, they are probably not complete as they should be.

-- 
Luigi

Re: KEXI, KDb, KProperty, KReport 3.1 ready to translate

[Luigi Toscano]

Jaroslaw Staniek ha scritto:
> 
> 
> On Saturday, 20 January 2018, Luigi Toscano  <mailto:luigi.tosc...@tiscali.it>> wrote:
>> Jaroslaw Staniek ha scritto:
>>> On 19 January 2018 at 19:13, Jaroslaw Staniek  <mailto:stan...@kde.org>> wrote:
>>>> On 19 January 2018 at 19:03, Luigi Toscano  <mailto:luigi.tosc...@tiscali.it>> wrote:
>>>
>>>>> Are you going to release from master, or are you going to create a 3.0 
>>>>> branch
>>>>> and we should copy the translations?
>>>>
>>>> 3.1 branch will be ready for stable 3.1.x releases today.
>>>
>>> Update. All 4 repos now have 3.1 branches and 3.0.94 tags.
>>> This time releaseme tools worked well, translations magically found in
>>> extragear-libs :)
>>> Kudos for that.
>>
>> Were they taken from the right branch? If they were taken from the existing
>> stable branch, 3.0, they are probably not complete as they should be.
> 
> From stable.

So those are still the old 3.0 translations. It's not too important because
it's a beta, but I'd suggest for next time to release from master just before
branching, including translations from master.

-- 
Luigi

Re: Calligra 3.1.0 stable branch created

[Luigi Toscano]

Il 26 gennaio 2018 13:27:26 CET, Dag  ha scritto:
>Please copy translations. (As usual exclude kexi/krita)

The branch was called Calligra/3.1 instead of the usual calligra/; 
please rename it.

Ciao

-- 
Luigi

Translation issues with the calligraplan documentation

[Luigi Toscano]

Hi,

it seems that the translations system does not work with the calligraplan
documentation. I believe the problem is connected with the way the split is
done: only the first top-level tag in each document is extract. If I remember
correctly we hit this problem in the past and we ended up with restructing the
 documentation, but I can't investigate right now.

-- 
Luigi

Re: Translation issues with the calligraplan documentation

[Luigi Toscano]

Dag ha scritto:
> Dag skrev den 2020-03-26 09:57:
> 
>> I have adjusted the structure so now xml2po extracts all texts, at least.
>>
>> Haven't tested if xml2po works.
>>
>> Also noted there are problems with keycode/keycap, but let's see if my
>> changes is enough to generate translated docs.
> 
> After further investigation it seems xml2po cannot handle docs that are split
> into several files (despite man page indicates so).

> Docbook operates by including files effectively creating one document out of
> all the files, while xml2po operates on each file individually. This means
> that entities etc will not be available to xml2po as you cannot have  tag in included files.

We do have documents split into multiple files. See for example kstars and
krusader. Please follow their structure.


> 
> A see two ways to fix this:
> 1) Make xml2po understand included files.
> 2) Have the whole document in one file.
> 
> A don't think 1) will happen soon, so I will go with 2).

I suggest to revert the change 2), or it will break all existing translations
and it will make the work on it very complicated. Again, we have examples of
documentation spanning multiple files.


-- 
Luigi

Re: Okular ODP generator translation

[Luigi Toscano]

Albert Astals Cid ha scritto:
> El Diumenge, 3 d'agost de 2014, a les 14:52:10, Burkhard Lück va escriure:
>> Am Sonntag, 3. August 2014, 12:42:07 schrieb Yuri Chornoivan:
>>> Hi,
>>>
>>> It seems that OkularOdpGenerator.cpp loads "okular_odp" catalog, renaming
>>> "okularGenerator_odp.mo" to "okular_odp.mo" solves the problem with not
>>> loading the translations in Okular ("Help -> About Backend").
>>>
>>> Can anybody help with moving okularGenerator_odp.po into okular_odp.po in
>>> trunk?
>>
>> This one liner patch would load the correct catalog as well without changing
>> the Messages.sh and renaming all existing catalogs:
>> $ git diff extras/
>> diff --git a/extras/okularodpgenerator/OkularOdpGenerator.cpp
>> b/extras/okularodpgenerator/OkularOdpGenerator.cpp
>> index 6c4afc3..3f935a4 100644
>> --- a/extras/okularodpgenerator/OkularOdpGenerator.cpp
>> +++ b/extras/okularodpgenerator/OkularOdpGenerator.cpp
>> @@ -44,7 +44,7 @@ static KAboutData createAboutData()
>>  {
>>  KAboutData aboutData(
>>   "okular_odp",
>> - "okular_odp",
>> + "okularGenerator_odp",
>>   ki18n( "ODP Backend" ),
>>   "0.1",
>>   ki18n( "ODP file renderer" ),
>>
>> What is the preferred solution?
>> 1) Yuri's changed Messages.sh and renaming of all catalogs
>> 2)  Patching OkularOdpGenerator.cpp
> 
> Personally i prefer the reverted Messages.sh + 2)
> 
> It's just smaller changes :D
> 
> Yuri, could you do that?

Before people start translating more and more, should I revert the change to
Messages.sh and change the catalog name? (cc- also calligra-devel)

Ciao
-- 
Luigi

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Switching branches for calligra translations

[Luigi Toscano]

Cyrille Berger Skott wrote:
> I am done. Hopefully it should be in order.

Thank you for moving them!  Just a quick note: there are messages marked as
fuzzy in stable now. The hypothesis (talking on #kde-i18n with Yuri) is that
scripty completed its run after you moved them, so the templates in stable are
currently wrong. Most probably  scripty will fix them and the translations
tomorrow, but for now:

Translators: do not touch the calligra stable branch till tomorrow.

As a general advice it's better to move messages when scripty is not running,
so before 1 AM CE(S)T (or UTC, I don't remember now) or after ~8:30 AM (same
timezone as starting time).

Ciao
-- 
Luigi
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Switch of translation branches (stable->2.8, trunk->master)

[Luigi Toscano]

Hi all,
this is a task you usually do, but this time, in a spring cleaning activity,
we moved the translations so that stable tracks 2.8 and trunk tracks master.

Could you please update the l10n branch setting in projects.kde.org?

Ciao
-- 
Luigi
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel