[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Centralized summit operations
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2014-09-19 14:23:25
Message-ID: 201409191623.27863.caslav.ilic () gmx ! net
[Download RAW message or body]


> The goal, at least for me, would be to automate as much as possible. What
> is the difference between posummit merge and the "dumb" merge?(I should
> read the documentation, I know)

The difference is as much as someone puts in the config file :) At default,
where nothing special is specified for merging, posummit does simply call
msgmerge inside and nothing else. What current summit team's config specify
are stuff like team-specific initialization of some header fields
(addresses, plural forms...), or automatic creation of empty PO files for
new templates.

>> A slight difference here is that the manual intervention is needed not
>> only after the gather, but also before. If some branch templates were
>> moved, deleted, etc, then 'posummit gather' will first stop with an error
>> message.
>
> Ok, ok, but we are already doing manual intervention also for scripty:
> when something changes, we fix the paths, we move files, etc. Why do we
> need to do this twice (on scripty configuration and on posummit)?

It is necessary to give posummit gather some hints, so that summit really
operates in a purposeful way.

For example. Imagine at one point there is catalog foo.pot, in both stable
and trunk branches. Then, the code of Foo in trunk is refactored such that
instead of single catalog it gets two, foo_app.pot and foo_lib.pot. If no
manual intervention is peformed, the summit would end up containing three
catalogs, foo.pot, foo_app.pot, foo_lib.pot, with most messages between
stable and trunk doubled. Instead, the following should be done. First into
the summit config a human adds the mapping of stable foo.pot to summit
foo_app.pot and foo_lib.pot. Then 'posummit gather' is started on the
templates summit with --create option, and since it sees this new mapping,
it will delete existing summit foo.pot, and create new summit foo_app.pot
and foo_lib.pot. They will end up containing the messages from trunk's
foo_app.pot and foo_lib.pot, as well as distributed among them any stable-
only messages from stable's foo.pot. Then, for language summits, a human
runs process orphans to copy old summit foo.po to new summit foo_app.po and
foo_lib.po (i.e. copy+copy+delete or copy+move).

> [...] For example, I'm not sure it's possible to configure some words to
> be different per branch (example: a translation changes - for various
> reason - between Qt4- and Qt5- based applications). This feature is the
> major blocker for the Italian team [...]
>
>> [...] If instead a translation team frequently likes to provide different
>> translations for different code branches, that largely reduces the
>> usefulness of summit.
>
> I still think the advantages would still be enough to consider summit.I'm
> talking about few words.

Well, depends on your team. Anything that you can define to support this,
can be added into the language-specific summit config as an action on
scatter. E.g. the solution I mentioned before ("blah ~@/old/new/ blah") is
already used in the sr summit, for a slightly different purpose. Here is
what would be added to LANG/summit/messages.extras.summit to provide this:

  from pology.resolve import resolve_alternatives
  S.hook_on_scatter_msgstr = [
      (lambda t, m, c: resolve_alternatives(t, 1, 2)[0], r"trunk|stable"), # -kde4
      (lambda t, m, c: resolve_alternatives(t, 2, 2)[0], r"future|fustable"), # -kf5
  ]

-- 
Chusslove Illich (Часлав Илић)

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]