slideshow.pot outdated

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

slideshow.pot outdated

opensuse.lietuviu.kalba
Hi,

During try install openSUSE Leap 42.1 RC1, found, that slides don't
refer to openSUSE 13.2, but slideshow.pot does. Last update of
slideshow.pot was almost one year ago.
https://bugzilla.opensuse.org/show_bug.cgi?id=950856

--
Mindaugas
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
On 18/10/2015 8:35, opensuse.lietuviu.kalba wrote:
> Hi,
>
> During try install openSUSE Leap 42.1 RC1, found, that slides don't
> refer to openSUSE 13.2, but slideshow.pot does. Last update of
> slideshow.pot was almost one year ago.
> https://bugzilla.opensuse.org/show_bug.cgi?id=950856

That .pot is in trunk, which now applies to Tumbleweed.
There is no translation branch for Leap, so we can't do anything.

Maybe after the migration to weblate is done and documented, we can try.

--
Saludos/Cheers,

   Carlos E.R. (Minas-Morgul - W10)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Richard Brown
On 18 October 2015 at 16:09, Carlos E.R. <[hidden email]> wrote:

> On 18/10/2015 8:35, opensuse.lietuviu.kalba wrote:
>>
>> Hi,
>>
>> During try install openSUSE Leap 42.1 RC1, found, that slides don't
>> refer to openSUSE 13.2, but slideshow.pot does. Last update of
>> slideshow.pot was almost one year ago.
>> https://bugzilla.opensuse.org/show_bug.cgi?id=950856
>
>
> That .pot is in trunk, which now applies to Tumbleweed.
> There is no translation branch for Leap, so we can't do anything.
>
> Maybe after the migration to weblate is done and documented, we can try.

You can translate it in Tumbleweed, and then ask the package
maintainer to do a very quick 'osc sr' from Factory to Leap

There is probably no trunk for Leap because there are no independent
packages for Leap - everything either comes from SLE, or Tumbleweed

(Which is why the Tumbleweed slideshow is currently talking about
Leap...yes, yes, I know, that's not ideal)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
On 18/10/2015 16:11, Richard Brown wrote:

> There is probably no trunk for Leap because there are no independent
> packages for Leap - everything either comes from SLE, or Tumbleweed

No. Trunk, in the translator team parlance, means "factory". There can
be no trunk for Leap or any other release. Each release has its own
branch, named after the release: 11.4, 12.3, 13.1, 13.2, trunk...

Possible hacks are to use trunk for leap temporarily, as you suggest,
but this can confuse things a lot, or to create a Leap branch on our
svn. Yes, I can probably do that, but I can't populate it with the right
files.

--
Saludos/Cheers,

   Carlos E.R. (Minas-Morgul - W10)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Richard Brown
On 18 October 2015 at 16:22, Carlos E.R. <[hidden email]> wrote:

> On 18/10/2015 16:11, Richard Brown wrote:
>
>> There is probably no trunk for Leap because there are no independent
>> packages for Leap - everything either comes from SLE, or Tumbleweed
>
>
> No. Trunk, in the translator team parlance, means "factory". There can be no
> trunk for Leap or any other release. Each release has its own branch, named
> after the release: 11.4, 12.3, 13.1, 13.2, trunk...
>
> Possible hacks are to use trunk for leap temporarily, as you suggest, but
> this can confuse things a lot, or to create a Leap branch on our svn. Yes, I
> can probably do that, but I can't populate it with the right files.


What is the point of a separate trunk for Leap, when the packages for
Leap are all coming from Tumbleweed/"factory"?

In the old days, it made sense, because we were doing the following

Split from Factory -> Create 'Release Project' (aka openSUSE:13.2) ->
Freeze 'Release Project', no automatic pulling from Factory any more,
only accept submissions from Devel Projects -> Have packages submitted
to that 'Release Project', such as translations

So, when you marry up the concept of translators trunks, and this
process, sure, makes sense, you needed to have your own trunk for each
release so everyone knew where those translations were targeted for

Now the process is totally different

Release Project was created Empty - openSUSE:Leap:42.1 -> No 'freeze'
in the traditional sense -> Packages pulled from SLE and Tumbleweed
based on maintainer request -> No packages expected from Devel
Projects

In this scenario, I really think the need for separate translator
'trunks' is redundant - the packager (a customer of your translations)
is just going to have to follow the exact same steps whether they were
putting the translations into Tumbleweed or Leap..might as well keep
it all in trunk and save them some effort

Unless I'm totally misunderstanding the entire process from both
sides..but I pretty much doubt that, think I'm getting a pretty good
handle on this translation thing now.. really enjoying using Weblate
to improve the en_GB translations.. ;)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-18 16:31, Richard Brown wrote:

> On 18 October 2015 at 16:22, Carlos E.R. <> wrote:
>> On 18/10/2015 16:11, Richard Brown wrote:
>>
>>> There is probably no trunk for Leap because there are no
>>> independent packages for Leap - everything either comes from
>>> SLE, or Tumbleweed
>>
>>
>> No. Trunk, in the translator team parlance, means "factory".
>> There can be no trunk for Leap or any other release. Each release
>> has its own branch, named after the release: 11.4, 12.3, 13.1,
>> 13.2, trunk...
>>
>> Possible hacks are to use trunk for leap temporarily, as you
>> suggest, but this can confuse things a lot, or to create a Leap
>> branch on our svn. Yes, I can probably do that, but I can't
>> populate it with the right files.
>
>
> What is the point of a separate trunk for Leap, when the packages
> for Leap are all coming from Tumbleweed/"factory"?

But they aren't, some come from SLES.

There are files that contain strings customized for the particular
release, like "welcome to Leap". The slideshow or the release notes
are obvious examples, but there are many more with subtle changes.

Then after a few months, Tumbleweed and Leap will diverge, and every
month more. We need a separate branch for Leap because if it doesn't
exist we can't handle any bugzilla after release.

>
> In this scenario, I really think the need for separate translator
> 'trunks' is redundant - the packager (a customer of your
> translations) is just going to have to follow the exact same steps
> whether they were putting the translations into Tumbleweed or
> Leap..might as well keep it all in trunk and save them some effort
>
> Unless I'm totally misunderstanding the entire process from both
> sides..but I pretty much doubt that, think I'm getting a pretty
> good handle on this translation thing now.. really enjoying using
> Weblate to improve the en_GB translations.. ;)

Check, for instance, KDE. They keep separate branches for each
maintained KDE release. The process is different: we translate one
branch, and migrate identical strings with specialized tools: be it
pology, gettext, lokalize... and weblate should do the same.

The packager doesn't need any extra effort. He just gets the exact
translation files for his projects. It is the translators who have to
merge them.

- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlYjv9YACgkQja8UbcUWM1z8pQD/VYStitmdCj9lEbs4tY4qzFLV
942iij6T8yjZ8HW8sLIA/19FuJUTbVJKBPnwRuQt0gMQ1lzb00z+aZi7F6Lse6bH
=s3cN
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Richard Brown
On 18 October 2015 at 17:50, Carlos E. R. <[hidden email]> wrote:

> Then after a few months, Tumbleweed and Leap will diverge, and every
> month more. We need a separate branch for Leap because if it doesn't
> exist we can't handle any bugzilla after release.

Yes, but the next Leap release (42.2, a year from now, maybe sooner)
will be built the same way, pulling from Tumbleweed and SLE.. are you
really expecting to be pushing out translations little by little over
the next months?

I would imagine something like translations is pretty much something
you want done before anyone puts in a DVD, because if the install
isn't properly translated..what does the rest matter if they cant
figure out how to install it?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-18 17:53, Richard Brown wrote:

> On 18 October 2015 at 17:50, Carlos E. R. <[hidden email]>
> wrote:
>
>> Then after a few months, Tumbleweed and Leap will diverge, and
>> every month more. We need a separate branch for Leap because if
>> it doesn't exist we can't handle any bugzilla after release.
>
> Yes, but the next Leap release (42.2, a year from now, maybe
> sooner) will be built the same way, pulling from Tumbleweed and
> SLE.. are you really expecting to be pushing out translations
> little by little over the next months?

I don't understand that.

It is done the same way as always: a new Leap_42.2 branch is created,
copying the files from Leap_42.1 and merging the new strings in
"trunk", for which we have tools and scripts.

And yes, during the lifetime of a release translation bugs are
reported, and we tend to them. The problem is generating a patch.


> I would imagine something like translations is pretty much
> something you want done before anyone puts in a DVD, because if the
> install isn't properly translated..what does the rest matter if
> they cant figure out how to install it?

It is often done after release for some languages; specially those
with small teams that simply can't cope. Yes, the installation will
not be translated for those, this round. But the programs will be
after yast online update.


- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlYjxKgACgkQja8UbcUWM1yJ4QD/WEGL20wOu/TLtgxuymxI5495
9nXi14Fp4ZBUfjHa8ncBAIv6P6XPR7yTNZmyKJiecGVyo4Rasw9vj9ldlYH23pX0
=n7BF
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Freek de Kruijf
In reply to this post by Carlos E. R.-3
Op zondag 18 oktober 2015 17:50:46 schreef Carlos E. R.:
> There are files that contain strings customized for the particular
> release, like "welcome to Leap". The slideshow or the release notes
> are obvious examples, but there are many more with subtle changes.
>
> Then after a few months, Tumbleweed and Leap will diverge, and every
> month more. We need a separate branch for Leap because if it doesn't
> exist we can't handle any bugzilla after release.

Not necessary. These texts can be made more general with parameters that
represent the distribution or the release version. This last information is
already present somewhere in the system

--
fr.gr.

member openSUSE
Freek de Kruijf

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-19 00:24, Freek de Kruijf wrote:

> Op zondag 18 oktober 2015 17:50:46 schreef Carlos E. R.:
>> There are files that contain strings customized for the
>> particular release, like "welcome to Leap". The slideshow or the
>> release notes are obvious examples, but there are many more with
>> subtle changes.
>>
>> Then after a few months, Tumbleweed and Leap will diverge, and
>> every month more. We need a separate branch for Leap because if
>> it doesn't exist we can't handle any bugzilla after release.
>
> Not necessary. These texts can be made more general with parameters
> that represent the distribution or the release version. This last
> information is already present somewhere in the system

So your idea is to have a generic .pot file with %s all over the place
to replace with "Leap" or "TW" at runtime? More work for the
developers? Or you propose to run a script to generate both texts, by
someone, and then save both texts somewhere, at the SVN or GIT?

Why not then, have two separate files?

What if the marketing team want to create different slide shows for
each version, highlighting the advantages of whatever one the user is
installing?

And that only covers the slide show.

What about, for instance, the developers adding the switch
"--heuristic" for "TW", which is not present in Leap? The help text
and the error messages for "TW" would be different than on "Leap". How
would you cover that?

That's why different branches for each release are needed.

- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlYkJo0ACgkQja8UbcUWM1xr0wEAnHW6ayjvUiGqtKNVVT31+B4J
qcIPbrsnz78N/BxiRP4BAJZaP6cyN6xupoK3QOVivxa3zWgbs8C0r8WDIM0Q95CZ
=Jsrl
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Karl Eichwalder
In reply to this post by opensuse.lietuviu.kalba
"opensuse.lietuviu.kalba" <[hidden email]> writes:

> During try install openSUSE Leap 42.1 RC1, found, that slides don't
> refer to openSUSE 13.2, but slideshow.pot does. Last update of
> slideshow.pot was almost one year ago.
> https://bugzilla.opensuse.org/show_bug.cgi?id=950856

I just updated and merged slideshow.pot in trunk (which is considered to
be released on Leap).

I hope I picked up the right file from the yast git.

--
Karl Eichwalder            SUSE Linux GmbH
R&D / Documentation        Maxfeldstraße 5
                           90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Freek de Kruijf
In reply to this post by Carlos E. R.-3
Op maandag 19 oktober 2015 01:09:01 schreef Carlos E. R.:

> On 2015-10-19 00:24, Freek de Kruijf wrote:
> > Op zondag 18 oktober 2015 17:50:46 schreef Carlos E. R.:
> >> Then after a few months, Tumbleweed and Leap will diverge, and
> >> every month more. We need a separate branch for Leap because if
> >> it doesn't exist we can't handle any bugzilla after release.
> >
> > Not necessary. These texts can be made more general with parameters
> > that represent the distribution or the release version. This last
> > information is already present somewhere in the system
>
> So your idea is to have a generic .pot file with %s all over the place
> to replace with "Leap" or "TW" at runtime? More work for the
> developers? Or you propose to run a script to generate both texts, by
> someone, and then save both texts somewhere, at the SVN or GIT?
>
> Why not then, have two separate files?

You still can have separate files and have these parameter used. So yes it is
work for the developers, but it also saves work for the translators. Less
items to translate.
 

> What if the marketing team want to create different slide shows for
> each version, highlighting the advantages of whatever one the user is
> installing?
>
> And that only covers the slide show.
>
> What about, for instance, the developers adding the switch
> "--heuristic" for "TW", which is not present in Leap? The help text
> and the error messages for "TW" would be different than on "Leap". How
> would you cover that?
>
> That's why different branches for each release are needed.

I am a simpleminded person who suggests simpleminded solutions. No must.

--
fr.gr.

member openSUSE
Freek de Kruijf

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Freek de Kruijf
In reply to this post by Karl Eichwalder
Op maandag 19 oktober 2015 10:39:13 schreef Karl Eichwalder:

> "opensuse.lietuviu.kalba" <[hidden email]> writes:
> > During try install openSUSE Leap 42.1 RC1, found, that slides don't
> > refer to openSUSE 13.2, but slideshow.pot does. Last update of
> > slideshow.pot was almost one year ago.
> > https://bugzilla.opensuse.org/show_bug.cgi?id=950856
>
> I just updated and merged slideshow.pot in trunk (which is considered to
> be released on Leap).
>
> I hope I picked up the right file from the yast git.

I committed the fully translated slideshow.nl.po file a few minutes ago.

--
fr.gr.

member openSUSE
Freek de Kruijf

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Martin Schlander
In reply to this post by Freek de Kruijf
Mandag den 19. oktober 2015 00:24:20 skrev Freek de Kruijf:

> Op zondag 18 oktober 2015 17:50:46 schreef Carlos E. R.:
> > There are files that contain strings customized for the particular
> > release, like "welcome to Leap". The slideshow or the release notes
> > are obvious examples, but there are many more with subtle changes.
> >
> > Then after a few months, Tumbleweed and Leap will diverge, and every
> > month more. We need a separate branch for Leap because if it doesn't
> > exist we can't handle any bugzilla after release.
>
> Not necessary. These texts can be made more general with parameters that
> represent the distribution or the release version. This last information is
> already present somewhere in the system

I'm pretty sure coolo said on the Factory mailinglist that the slideshow is
intended for Leap only (mainly), when some tumbleweed user commented on it.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Karl Ove Hufthammer
In reply to this post by Richard Brown
Den 18. okt. 2015 17:53, Richard Brown skreiv:
>> >Then after a few months, Tumbleweed and Leap will diverge, and every
>> >month more. We need a separate branch for Leap because if it doesn't
>> >exist we can't handle any bugzilla after release.
> Yes, but the next Leap release (42.2, a year from now, maybe sooner)
> will be built the same way, pulling from Tumbleweed and SLE..

In principle, this should be very simple: The translations must follow
the source code.

For example, if the tool ‘foo’ in Leap is taken directly from the
‘master’ branch of the ‘foo’ Git repository, the translation template
must be taken from the same place. If it’s taken from a different
branch, there must be similar translation branch.

Now, in one years time, or perhaps 6 weeks time (for an urgent security
fix), there may be an update to the ‘Leap’ package. If this taken from
master in Git, there will be no problems (as long as the translation
templates are continuously kept up to date, e.g. with daily updates).
But if it’s decided that ‘Leap’ should be ‘stable’, so only security
updates (which may also add or changes some strings) are applied, not
bigger changes (new features), the source code will be in another place
(e.g. a ‘SLES12’ branch in Git or a ‘Leap’ branch in Git). And then
there must be a corresponding translation branch.

So it *may* be that only two translation branches are needed, ‘trunk’
and ‘stable’ (currently called SLES12 in SVN). Or it may be that more
than one branch is needed (e.g. ‘Leap’, if there exists packages that
are taken neither from SLES12 or ‘trunk’/‘master’/Factory). That all
depends on whether all future packages (and updates to these packages)
take their source code only from SLES12 and Factory, or from other
places (branches) too.

So again: The translations must follow the source code. If the source
code a package is built from changes, so must the translation template
files.

> are you really expecting to be pushing out translations little by little over
> the next months?

That’s the *normal* way translations work in free software projects. Few
teams have the resources to fully translate *all* the software (in a
distro, or a larger software compilation, like KDE) before the release
*and* to thoroughly review and QA test all strings, especially since the
source is commonly updated all the way up to the release date (though
there is usually an official ‘string freeze’ a few weeks earlier).

So updated translations – additional strings translated and improvements
to previously translated strings – are therefore usually included in any
future package updates. These package updates may be because of security
issues, important bug fixes, or perhaps rebuilt packages because of
dependencies from other packages. And some free software projects also
issue updates just to include updated translations.

--
Karl Ove Hufthammer
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Karl Ove Hufthammer
In reply to this post by Freek de Kruijf
Den 19. okt. 2015 00:24, Freek de Kruijf skreiv:
>> There are files that contain strings customized for the particular
>> >release, like "welcome to Leap". The slideshow or the release notes
>> >are obvious examples, but there are many more with subtle changes.
>> […]
> Not necessary. These texts can be made more general with parameters that
> represent the distribution or the release version. This last information is
> already present somewhere in the system

Note that (i.e. using strings like ‘Welcome to %1’) is against ‘best
practice’ for localisation. See for example
https://www.gnu.org/software/gettext/manual/html_node/Names.html

    Should names of persons, cities, locations etc. be marked for
    translation or not? People who only know languages that can be
    written with Latin letters (English, Spanish, French, German, etc.)
    are tempted to say “no”, because names usually do not change when
    transported between these languages. However, in general when
    translating from one script to another, names are translated too,
    usually phonetically or by transliteration. For example, Russian or
    Greek names are converted to the Latin alphabet when being
    translated to English, and English or French names are converted to
    the Katakana script when being translated to Japanese. This is
    necessary because the speakers of the target language in general
    cannot read the script the name is originally written in.


And no, this won’t be fixed by having ‘Leap’ and ‘Tumbleweed’ as a
separate translatable strings either, as a some language feature noun
inflection.

But having proper, complete, localisable strings like ‘Welcome to Leap’
and ‘Welcome to Tumbleweed’ *will* fix it.

--
Karl Ove Hufthammer
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
In reply to this post by Karl Ove Hufthammer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-19 21:16, Karl Ove Hufthammer wrote:

> Den 18. okt. 2015 17:53, Richard Brown skreiv:
>>>> Then after a few months, Tumbleweed and Leap will diverge,
>>>> and every month more. We need a separate branch for Leap
>>>> because if it doesn't exist we can't handle any bugzilla
>>>> after release.
>> Yes, but the next Leap release (42.2, a year from now, maybe
>> sooner) will be built the same way, pulling from Tumbleweed and
>> SLE..
>
> In principle, this should be very simple: The translations must
> follow the source code.

Correct.

> For example, if the tool ‘foo’ in Leap is taken directly from the
> ‘master’ branch of the ‘foo’ Git repository, the translation
> template must be taken from the same place. If it’s taken from a
> different branch, there must be similar translation branch.

Absolutely.


> Now, in one years time, or perhaps 6 weeks time (for an urgent
> security fix), there may be an update to the ‘Leap’ package. If
> this taken from master in Git, there will be no problems (as long
> as the translation templates are continuously kept up to date, e.g.
> with daily updates). But if it’s decided that ‘Leap’ should be
> ‘stable’, so only security updates (which may also add or changes
> some strings) are applied, not bigger changes (new features), the
> source code will be in another place (e.g. a ‘SLES12’ branch in Git
> or a ‘Leap’ branch in Git). And then there must be a corresponding
> translation branch.

Correct.

>
> So it *may* be that only two translation branches are needed,
> ‘trunk’ and ‘stable’ (currently called SLES12 in SVN). Or it may be
> that more than one branch is needed (e.g. ‘Leap’, if there exists
> packages that are taken neither from SLES12 or
> ‘trunk’/‘master’/Factory). That all depends on whether all future
> packages (and updates to these packages) take their source code
> only from SLES12 and Factory, or from other places (branches) too.

Yes, that is correct. Although I would name the translation branches
the same as the code branches. Ie, tumbleweed (the current trunk), and
Leap. If two releases of Leap will coexist at some time (I understand
this is not yet decided), then each one needs its separate branch.


> So again: The translations must follow the source code. If the
> source code a package is built from changes, so must the
> translation template files.

Absolutely.


>> are you really expecting to be pushing out translations little
>> by little over the next months?
>
> That’s the *normal* way translations work in free software
> projects. Few teams have the resources to fully translate *all* the
> software (in a distro, or a larger software compilation, like KDE)
> before the release *and* to thoroughly review and QA test all
> strings, especially since the source is commonly updated all the
> way up to the release date (though there is usually an official
> ‘string freeze’ a few weeks earlier).

Yes.

> So updated translations – additional strings translated and
> improvements to previously translated strings – are therefore
> usually included in any future package updates. These package
> updates may be because of security issues, important bug fixes, or
> perhaps rebuilt packages because of dependencies from other
> packages. And some free software projects also issue updates just
> to include updated translations.

Yes.

We have, in fact.


- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlYlR24ACgkQja8UbcUWM1wrcgD/SEyoVG2Qt9XgE4S1G7HeEtHK
Y7q6X2tgvX3WvEfqvSYA/3yQsGpmTWuYe8WXcciM87II9palJO/NnOyYPoW9G7rd
=tyqA
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Carlos E. R.-3
In reply to this post by Karl Ove Hufthammer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2015-10-19 21:27, Karl Ove Hufthammer wrote:

> But having proper, complete, localisable strings like ‘Welcome to
> Leap’ and ‘Welcome to Tumbleweed’ *will* fix it.

Yes, this is what I thought, but I was having doubts. Thanks for
confirming :-)

- --
Cheers / Saludos,

                Carlos E. R.

  (from 13.1 x86_64 "Bottle" (Minas Tirith))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlYlSBAACgkQja8UbcUWM1yi9QD/SlzVnZFpIXgZVLrvRDOO01nm
WBm3q4f/ZUWc4i4KXmAA/2d/0uT7bkcCam97UcSbD4Nz2SIWh8FJ+TR+uahQmO/8
=4gl8
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Karl Eichwalder
In reply to this post by Karl Ove Hufthammer
Karl Ove Hufthammer <[hidden email]> writes:

> But having proper, complete, localisable strings like ‘Welcome to Leap’
> and ‘Welcome to Tumbleweed’ *will* fix it.

In general, that's not wrong ;)

But for computer products it is sometimes a tad different.  For example,
the Japanese Wikipedia knows about OpenSUSE, etc.:

https://ja.wikipedia.org/wiki/OpenSUSE

--
Karl Eichwalder            SUSE Linux GmbH
R&D / Documentation        Maxfeldstraße 5
                           90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: slideshow.pot outdated

Karl Ove Hufthammer
Den 20. okt. 2015 09:44, Karl Eichwalder skreiv:

> Karl Ove Hufthammer<[hidden email]>  writes:
>
>> >But having proper, complete, localisable strings like ‘Welcome to Leap’
>> >and ‘Welcome to Tumbleweed’*will*  fix it.
> In general, that's not wrong;)
>
> But for computer products it is sometimes a tad different.  For example,
> the Japanese Wikipedia knows about OpenSUSE, etc.:
>
> https://ja.wikipedia.org/wiki/OpenSUSE

As explained in the links, this is *language-dependent*, and that’s why
the complete strings must be translatable. According to Wikipedia
(https://ar.wikipedia.org/wiki/%D8%A3%D9%88%D8%A8%D9%86_%D8%B3%D9%88%D8%B2%D9%8A),
in Arabic, openSUSE is called

   أوبن سوزي

(which Google Translate tells me is pronunced ‘uwban suzi’, which seems
accurate enough.)

And in one of the Arabic translation files, the string ‘SUSE Linux
Enterprise 11 SP1’ is translated into ‘حزمة الخدمة SP1 مشروع سوزي لنكس
11’, so even the position of the version info in the strings can be
different than in English.

--
Karl Ove Hufthammer
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12