Re: What is the status of developer.gnome.org and help.gnome.org?

[Petr Kovar]

On Mon, 18 Feb 2019 08:42:28 -0500
Shaun McCance  wrote:

> On Fri, 2019-02-15 at 20:19 +, Emmanuele Bassi via desktop-devel-
> list wrote:
> > Given the state of library-web’s maintenance and resources, I’m
> > actually
> > trying to figure out a way to use Gitlab’s CI to build the
> > documentation
> > and put it somewhere else; I still have to investigate how to achieve
> > this
> > on the GNOME infrastructure.
> 
> I'd like to switch help.gnome.org to use Pintail. I have a very rough
> work in progress of such a setup here:
> 
> https://gitlab.gnome.org/shaunm/help.gnome.org
> 
> It builds straight from git branches. Tarballs are irrelevant.

I think this switch should be the docs project's primary goal for the next
release cycle, and I'm hoping we can get the necessary support from Infra
and other groups in the community to make this happen. 

> There's also a group of people wanting to do something else for the
> developer site. I went to some of their meetings, but haven't had time
> to keep up. I don't know their status.

Same here. I think if the developer site group chooses at some point to
go for the same solution as the user help site, they can just do it by
re-using parts of the infra setup, though from what I understood the
group's goal was to switch to a Drupal-like CMS. Any updates there?

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: What is the status of developer.gnome.org and help.gnome.org?

[Petr Kovar via desktop-devel-list]

On Fri, 15 Feb 2019 20:19:11 +
Emmanuele Bassi via desktop-devel-list  wrote:

> Hi Joanne;
> 
> the switch to Meson for various libraries broke the expectations of
> library-web, which is used to populate developer.gnome.org. The scripts
> expect the HTML for the API reference to be in the release tarballs, but
> that’s not the case for Meson-generated dist archives.
> 
> GTK and GLib use a separate location to manually upload documentation
> tarballs; this needs configuration changes in library-web, and manual
> documentation generation on the maintainers side.
> 
> Given the state of library-web’s maintenance and resources, I’m actually
> trying to figure out a way to use Gitlab’s CI to build the documentation
> and put it somewhere else; I still have to investigate how to achieve this
> on the GNOME infrastructure. In the meantime, you could check in the
> Infrastructure/library-web repository for the configuration changes needed
> to use an external tarball for the documentation, and open a merge request
> to enable it for ATK and other libraries.

The tarball names should be included here:

https://gitlab.gnome.org/Infrastructure/library-web/blob/master/data/extra-tarballs

Though I see atk is already there.

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moving keyboard shortcuts list from help to app (was: Retiring app menus - planning for 3.32.0)

[Petr Kovar]

On Sun, 9 Dec 2018 11:16:28 -0500
Jeremy Bicha  wrote:

> On Thu, Sep 20, 2018 at 7:22 AM Andre Klapper  wrote:
> > Personally I've always wondered how the "Keyboard Shortcuts" item
> > potentially duplicates dedicated pages in some user docs, such as
> > https://help.gnome.org/users/gnome-help/stable/shell-keyboard-shortcuts.html
> > https://gitlab.gnome.org/GNOME/evolution/blob/master/help/C/intro-keyboard-shortcuts.page
> >  [1]
> > https://help.gnome.org/users/five-or-more/stable/shortcuts.html
> > https://help.gnome.org/users/iagno/stable/shortcuts.html
> >
> > Maybe agreeing on a skeleton (strings to translate only once across
> > repos if you use software with a translation memory) / guidelines for a
> > shortcuts Mallard help page (and page name) is an option?
> 
> I've been adding the Keyboard Shortcuts dialogs to several games as
> part of the 3.32 app menu updates and I've run into this duplication
> issue. I'd like to remove the Keyboard Shortcuts page from the help
> for these games.
> 
> Especially with the GNOME 3.32 app menu design, it's really easy to
> find Keyboard Shortcuts now.

Good point. 

Technically, you can still reference the page from gnome-help in your app
docs, for example:

  

This might invalidate the Mallard syntax (yelp-check won't be
able to find the resource locally), but it won't break the build. The
reference will work locally only if gnome-user-docs is installed, and
it won't work online (no implementation for it in library-web.

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab minor-reorganization to Community group

[Petr Kovar]

On Fri, 14 Sep 2018 10:58:30 +0200
Andre Klapper  wrote:

> [CC'ing gnome-i18n@]
> 
> On Mon, 2018-09-10 at 11:46 -0600, Britt Yazel wrote:
> > There's been an ongoing discussion about reorganizing the "community"
> > top level group from containing both our community partner repos
> > (purism, ubuntu, fedora) as well as a myriad of other repositories.
> > As of right now, the Community top level is somewhat of a catch-all,
> > and we have proposed a fix to split Community into both 'Community'
> > and 'Teams' repositories, with the new 'Teams' top level being where
> > we will organize all of our Foundation teams, i.e. Engagement,
> > Design, Translation, Events, etc.
> [...]
> > https://gitlab.gnome.org/Infrastructure/GitLab/issues/294#note_280162
> 
> Re Translation:
> 
> It's unclear to me where in Gitlab people are supposed to file bug
> reports against a translation in a specific language, which would allow
> translators of a language to get aware of bugs in their translations.
> 
> There is a "8. Translation" label at
> https://gitlab.gnome.org/groups/GNOME/-/labels which allows subscribing
> but does not allow differentiating per language. It should probably be
> renamed to "8. Internationalization" and only be about code which does
> not allow proper translation; the label description could link to
> https://wiki.gnome.org/TranslationProject/DevGuidelines .
> 
> Currently there is an "L10N" product in GNOME Bugzilla with
> subcomponents for each language. Each subcomponent can be watched
> separately by folks interested in that subcomponent (=language).
> 
> Maybe some Gitlab setup / ideas already exists that I'm not aware of?

Can we use https://gitlab.gnome.org/Community/Translation and set up
translation teams as issue labels there?

Alternatively, we could make Community/Translation a group and set up
languages as individual projects within that team. That could give teams
a better control over where and how to submit issues against their language.

My 5¢.

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Let's pause meson migration in preparation for the 3.26 release

[Petr Kovar]

On Fri, 11 Aug 2017 11:21:05 -0500
Michael Catanzaro  wrote:

> On Fri, Aug 11, 2017 at 10:59 AM, Jeremy Bicha  
> wrote:
> > If you want to do these things, please branch for 3.26 and make your 
> > changes to git master for 3.27/3.28.
> > 
> > Please do continue to fix bugs in the meson build for your modules.
> 
> Thanks Jeremy! This is a good rule to follow.
> 
> I do encourage projects to remove their Autotools build systems as soon 
> as reasonable, since having to support two build systems is causing 
> many problems. But it's probably not reasonable to do so at this point 
> until after you've first branched for gnome-3-26.

Related to this, when migrating your module, please do keep in mind that
Damned Lies support for Meson modules is still incomplete, see
https://bugzilla.gnome.org/show_bug.cgi?id=783099.

As Piotr reported elsewhere [1], totem-pl-parser, nautilus-sendto, and
gnome-bluetooth have broken/incomplete i18n support as a result.

Your help with fixing #783099 would be much appreciated.

Thanks,
pk

[1] https://mail.gnome.org/archives/gnome-i18n/2017-August/msg00015.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Screenshot automation BoF at GUADEC

[Petr Kovar]

Hi,

On Mon, 14 Jul 2014 17:43:51 +0200
Alexandre Franke alexandre.fra...@gmail.com wrote:

 Hi,
 
 It's 2014 and translators and documentation writers still have to
 spend a lot of time to manually create screenshots. There must be a
 better way. Therefore I'm planning a half-day BoF on this topic at
 GUADEC.
 
 This is relevant to you if you're a translator or writer, but we also
 hope people with experience in automated UI testing will show up to
 give us a hand.

Thanks a lot for kicking this off, Alexandre. This is a great agenda for a
shared i18n-L10n-docs session we have been planning to do, so count me
in. :-)

It looks like many people are leaving on the 31st (myself included), so
could we do this on the 30th?

I also updated https://wiki.gnome.org/TranslationProject/Events so
that we have the relevant wiki pages in sync.

Cheers,
pk
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git submodules vs translators

[Petr Kovar]

Hi all,

Colin Walters walt...@verbum.org, Thu, 27 Jun 2013 20:01:33 -0400:

 The use of git submodules in GNOME is growing - there's libgd,
 egg-list-box, and my own libgsystem, among others.  Broadly speaking, I
 think that's a good thing.  They offer a reasonable set of tradeoffs
 compared to copylibs like the old libegg model.
 
 However, git submodules are easy to screw up unless everyone committing
 to the repository is aware of how they work.  This collides badly with
 our current translation system where many translators commit directly to
 git, resulting in commits like this one:
 
 https://git.gnome.org/browse/gnome-control-center/commit/?id=c87483acb4cce36ffad215396dbaa4cea801c970
 
 That commit reverted two submodules.  The gnome-ostree continuous
 integration system made it fairly obvious when I looked at the build
 error, but two things should happen:
 
 1) Translators:  Ensure you run git submodule update --init after
every git pull.

Thanks for bringing this up.

We already suggest in one of our GNOME L10n HOWTOs that translators
set up a git alias for git pull --rebase, so we may just need to expand
it to talk about an alias for git pull --rebase  git submodule
update --init:

https://wiki.gnome.org/TranslationProject/GitHowTo

 2) We need some sort of sanity check in a pre-receive hook.  Something  
like commits whose subjects match the regexp Update.*translation
are rejected if they modify submodules.

Not all translators seem to use the same commit messages, so instead, we
probably want to check for commits changing *.po files in po*/ dirs or
something like that...

Or even stronger, one idea is that modules can opt-in to having a
file submodule-check which must change content for commits which
update submodules.  The downside of that is it would conflict
on branch merges, but then again, the submodules would anyways.
 
 Any other thoughts?

I agree with Fred that having 
https://bugzilla.gnome.org/show_bug.cgi?id=599066 addressed would
definitely help us, also in terms of making the whole translation process
easier and more straightforward, especially for translators who are less
experienced or technical.

Cheers,
Petr Kovar
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moduleset Reorganization -- Take two

[Petr Kovar]

Hi!

Kenneth Nielsen k.nielse...@gmail.com, Thu, 14 Oct 2010 10:34:13 +0200:

(...)

 If I give it my best at being a little frexible, I think we can make
 it work from a l10n point of view. The key is information and
 overviews. I think not everybody understands just exactly how
 important damned lies like functionality is to us translators and how
 much we use it. The reason is that we usually touch a lot more modules
 than any other contributor group. We frequently browse through lists
 to find work and access progress. So if... the Apps module set will
 have its own page in damned lies and if... string freeze and release
 dates are present there on that overview list, for the apps that don't
 follow the GNOME release schedule, and if the number of those apps
 are kept low, then I think that is still a workable solution.

If asynced release schedules eventually become reality for official GNOME
modules wherever they might be hosted (I still hope it's avoidable, though),
I think many GNOME translators would really appreciate having the following
as a hard requirement:

* string freeze period lasting for a reasonable amount of time (some might
think that having a string freeze for two days is enough, well, it is not),

* string freeze break requests handled the same way that it is now,

* release schedule presented on a special overview page at our l10n
infrastructure, timely (as Kenneth writes; probably less suitable way would
be to announce it to the gnome-i18n mailing list, as it is done now
voluntarily by some enlightened maintainers of unofficial modules (thank
you!).

Surely, having no synced schedule is barely an improvement for l10n
support. Among other things, translators would be unable to do some
common changes (e.g. terminology or QA fixes) throughout moduleset in one
step just before the stable (or development) release.

My 33 hellers,
Petr Kovar
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: Clutter core

[Petr Kovar]

Hi!

Matthias Clasen matthias.cla...@gmail.com, Thu, 7 Oct 2010 07:55:42 -0400:

 On Thu, Oct 7, 2010 at 7:51 AM, Vincent Untz vu...@gnome.org wrote:
 
  I think the right solution is to improve l10n.gnome.org so that it can
  interacts with other platforms (like transifex) where there is a team
  control.
 
  Alternatively we can also investigate something similar to where
  transifex is heading to: host the po files on l10n.gnome.org and add
  some autofoo magic that would download the po files from there during
  'make dist'.
 
 I think moving toward transifex or a similar distributed approach for
 translations is the way to go.

When it comes to consistency in translation (which matters), not
distributed approach, but centralized effort of community is the key to
success. That's what I learned from several years of translating FLOSS
projects. And I guess that other translators observed that as well.

My 10 hellers though,
Petr Kovar
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moduleset Reorganization -- Take two

[Petr Kovar]

Hi!

Michael Terry m...@mterry.name, Fri, 8 Oct 2010 10:30:14 -0400:

 On 8 October 2010 03:13, Johannes Schmid j...@jsschmid.de wrote:
  The best solution IMHO would be to import PO files for all
  applications, and integrate them into Damned Lies. Else, we're taking
  the risk of losing consistency, and « moduleset » won't mean anything
  in the end.
 
  I am afraid that the problem is not to import PO files in damned-lies
  but to commit them from damned-lies to the repositories. And we have to
  find a solution for this while keeping the current permissions that are
  specific to git.gnome.org.
 
 From a Launchpad perspective, a translation branch can be imported
 from git into a bzr branch in Launchpad.  This would involve zero
 change from an LP maintainer perspective (currently, there is a bzr
 branch in LP for translations that gets written to by translators
 through the web interface; maintainers merge that branch before a
 release).
 
 So the trick then would be having Damned Lies import pot/po files from
 a bzr trunk.  Then GNOME translators can edit them in git like they
 like.  Then LP can import that translation branch with changes.
 
 Eh?

I think that would be very acceptable to GNOME translators, while keeping
the main development at a location of developer's preference.

(CC'ing gnome-i18n as this is definitely of interest to the members of that
group as well.)

Best,
Petr Kovar
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Modulesets Reorganization

[Petr Kovar]

Hi all!

Other GNOME translators have already commented on this proposal, but I
thought I'd share some of my views from the i18n/l10n point of view anyway.

Michael Terry m...@mterry.name, Wed, 2 Jun 2010 08:54:49 -0400:

 On 1 June 2010 19:37, Lucas Rocha luc...@gnome.org wrote:
  3. We strongly believe that we should encourage a strong ecosystem of
  apps around GNOME, and integrating all applications in the GNOME
  Desktop moduleset is not the best way to achieve this.
 
 As the maintainer of Déjà Dup, I approve of this move.  I feel Déjà
 Dup is a bit of a poster child for this change.

Please note that the said proposal would very likely affect the l10n
processes for many modules in a rather negative way. In particular, not
providing (or not being required to do so) the translators a possibility
for a sufficiently long string freeze period means that they aren't able and
motivated to work on completing the l10n task before the module release.

So I think, since i18n and l10n have long been core values for the GNOME
Project, that having a clear release schedule and string freeze period
shouldn't be just appreciated  encouraged from GNOME module maintainers,
but simply required in order to ensure that GNOME l10n in a variety of
languages is complete, consistent, and of reasonable quality.

Furthermore, GNOME maintainers should always enable translators from the
GNOME Translation Project (only) to work on module l10n using GTP in-house
infrastructure. Adhering to other l10n projects or infrastructures goes
against the fact that not other l10n project, but the GTP is and has been
responsible for how the GNOME software is localized.

The way how code development works is often confused with how l10n works,
but these processes are different. For a working l10n effort, it's often
quite more important to make use of centralized, normative infrastructure
for a set of software projects that are to be localized with standardized
team work flow, task planning, providing and sharing best practices, incl.
sufficient consistency in translation terminology, style, etc. This all can
be hardly accomplished when you have to deal with zillions of different
l10n platforms, teams, release schedules and so on.

In other words, working on GNOME translations should mean working within
one translation project, with one language team, on one platform.

So as I'm quite concerned over the future of the GNOME l10n efforts, it's my
hope that the reorganization proposal won't be approved in its current form.

Thanks,
Petr Kovar
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list