Removing older versions of strings from pootle

l10n
#1

Hi,
As older versions like LibO 3.3.x are no longer used in pootle for
translation, I suggest removing all of them from pootle, so we will
have a single version of strings available on pootle. Each package
should be upgraded before removing the older version. For example, we
still have the old version of the extensions project. This prevents
confusion of translators, and also creates a real continuous
translation process.
I also suggest removing version number from the name of the projects,
because it has several benefits. One of them is preserving
contribution statistics of the project.

#2

As older versions like LibO 3.3.x are no longer used in pootle for
translation, I suggest removing all of them from pootle, so we will
have a single version of strings available on pootle. Each package
should be upgraded before removing the older version. For example, we
still have the old version of the extensions project. This prevents
confusion of translators, and also creates a real continuous
translation process.

LibO 3.3.x is not dead, there will be at least one release from that
branch and translations can be updated/completed.

Extensions are special. Only NLPSolver is bundled to LibreOffice. It
does not matter if it is labeled as 3.3 or 3.4 because the version of
NLPSolver is the same in both branches. The other extensions are not
bundled. In fact, I think we should create an independent module for
each extension, providing that someone volunteers to manage them (i.e.
take the translations and push them upstream).

I also suggest removing version number from the name of the projects,
because it has several benefits. One of them is preserving
contribution statistics of the project.

That's a good point. Statistics are important. I wonder what others
think. Should we always translate the current version under
development? It would be still possible to send patches and/or updated
po files for stable versions, because translations are stored in git,
too.

Best regards,
Andras

#3

Hi,

I also suggest removing version number from the name of the projects,
because it has several benefits. One of them is preserving
contribution statistics of the project.

That's a good point. Statistics are important. I wonder what others
think.

I wonder why it should be important for the statistics if we have Version numbers in the project or not. If someone is actually doing a translation this is counted - and that is what matters (regardless of the version she contributed to).

Should we always translate the current version under
development? It would be still possible to send patches and/or updated
po files for stable versions, because translations are stored in git,
too.

I'd like to see the the development brach and the "current stable but in bugfix-mode" version in pootle. It's by far more easy to trasnaltors to fix translation issues at the same place where they did the full translation - so whoever is using pootle to do translations will likely do bug fixing through pootle as well.

As second point: in OOo we had several languages that (due to lack of personal resources) could not deliver 100% translation in time. These languages got in troubles, when the "old but stable" strings got replaced with the new developer version.

So although it was not really planned that way, I like the current situation to have the strings for at least two LibO-Versions in pootle.

regards,

André

#4

By using project names such as "libo-current-ui" and "libo-next-ui" you could achieve this statistics stability, if required. The descriptive name of the project could then communicate that this is 3.3.x vs 3.4.x

#5

2011.04.18. 11:54 keltezéssel, Dwayne Bailey írta:

Hi,

I also suggest removing version number from the name of the projects,
because it has several benefits. One of them is preserving
contribution statistics of the project.

That's a good point. Statistics are important. I wonder what others
think.

I wonder why it should be important for the statistics if we have
Version numbers in the project or not. If someone is actually doing a
translation this is counted - and that is what matters (regardless of
the version she contributed to).

By using project names such as "libo-current-ui" and "libo-next-ui" you
could achieve this statistics stability, if required. The descriptive
name of the project could then communicate that this is 3.3.x vs 3.4.x

But at some point I need to move libo-next-ui to libo-current-ui and
create a new libo-next-ui. IMHO it's not a rename operation. Or is it?

Anyway, André is right, statistics per language should be enough. It
would be the best, if I didn't have to change anything in our current
setup. :slight_smile:

Thanks,
Andras

#6

Hi,
I have to remind that we're in a situation that we only have one
legacy branch. Sooner or later, we will have multiple versions of LibO
strings available on pootle, that not only make the workspace crowded,
but downloading zip folders and operations like this on them, make
pootle slow.
When pootle can't do things in parallel, we can partition the job
logically and put it on multiple servers to gain speed up. So, Why not
setup a pootle instance for legacy strings? All the previous versions
can go there so everyone that needs them can still use it without
switching to a new traslating interface.
Migeration would also be easy. MySQL tables and files are copied to
the server that holds legacy files.
On the other hand, an upgrade on the current version, keeps everything in place.
Anyway, someday in near future we'll have to remove older versions, so
why not create a guideline for the lifecycle of those old strings and
keep them in a good place?

Hossein

#7

Hi Hossein,

2011.04.19 16:08, Hossein Noorikhah rašė:

I have to remind that we're in a situation that we only have one
legacy branch. Sooner or later, we will have multiple versions of LibO
strings available on pootle, that not only make the workspace crowded,
but downloading zip folders and operations like this on them, make
pootle slow.
When pootle can't do things in parallel, we can partition the job
logically and put it on multiple servers to gain speed up. So, Why not
setup a pootle instance for legacy strings? All the previous versions
can go there so everyone that needs them can still use it without
switching to a new traslating interface.

Disclaimer: the following is my personal impression.
I don't (yet) think this makes much sense for one simple reason: as far as I remember from OOo, and looking at what we have now, it simply doesn't seem like LibO would be releasing from two or more branches simultaniously often and for long times. Unlike Mozilla. This makes excessive server load from working on old strings quite unlikely in my eyes. I think such load would be more occasional than usual, so in my opinion, it simply doesn't justify maintaining two totally independent installations of Pootle and keeping them in sync with each other.

On the other hand, an upgrade on the current version, keeps everything in place.
Anyway, someday in near future we'll have to remove older versions, so
why not create a guideline for the lifecycle of those old strings and
keep them in a good place?

I think the policy here is quite simple: when there is a decision that there will be no more releases from a certain branch, then that branch should be dropped from Pootle.

Rimas