Today I noticed that a new release of Lazarus is prepared (time of last update on sf.net 'Files' page is newer than the release time of listed files).

I am updating the translations each time the source po files are changing. But it's not a good idea to release them on the bug-tracker every time when a single sentence or just a word was changed. So I am asking you (the release manager) to send out a notification (on the mailing list of course) when you know that no more source strings will be changed before publishing the new version...
This way the translators and the manager of translations will have time to upload their work.

Mantis' RoadMap is not (and never was) up to date. Today it shows the followings
"Lazarus - 1.4.2 (Scheduled For Release 2015-06-20" and
"0028167: [LCL] MaskUtils.FormatMaskText not implemented (Bart Broersma)
- assigned."

So where can we know that we can upload the translations without missing future changes?

A true release model with strict phases (including "frozen source strings" at last, maybe two weeks) would be very useful.

For example see: http://www.xfce.org/about/releasemodel

Today I noticed that a new release of Lazarus is prepared (time of last update on sf.net 'Files' page is newer than the release time of listed files).

Yes, 1.4.2. It is a bug fix release. No new features.

The 'fixes' branch only contains bug fixes. So almost all changes to resourcestrings are either fixing typos of the English version or add new error messages.

Waiting a week means translators and maintainers must work with an additional branch.

I'm not sure if it is worth the hassle. Maybe Maxim who applies the biggest part of the translations can tell.

Mattias

11.07.2015 22:24, Mattias Gaertner ?????:

Yes, most of translations changes are string additions, i.e. some string in interface was untranslatable before and then resource string got added for it. This doesn't cause translation regressions.

Sometimes some strings get changed though, but such changes are quite rare.

Waiting a week means translators and maintainers must work with an additional branch. I'm not sure if it is worth the hassle. Maybe Maxim who applies the biggest part of the translations can tell.

I agree here, there is not so much translations changes in fixes branch anyway.

BTW, in case of 1.4.2 release the LAST merge affecting resource strings was done a MONTH AGO, on June 11.

I would recommend translators to send translation updates for FIXES branch as soon as they have trunk it is enough to send them once a week.

2015-07-12 14:54 keltez?ssel, Maxim Ganetsky ?rta:

In my life (and work) I try to deal with resources sparingly. So I don't think that the good solution is to pollute the bug-tracker's database with large files because of some short sentences.

2015-07-11 21:24 keltez?ssel, Mattias Gaertner ?rta:

Here I was talking about any/all releases not only the current bugfix release.

Waiting a week means translators and maintainers must work with an additional branch.

If the bug-tracker's roadmap shows scheduled releases with date in the (far) past and with open/pending issues then nobody can seriously think that everything is ready and you are just waiting for translators and maintainers to finish their job... and nobody can know the time when the "waiting a week" was started, especially if unsolved issues are listed in the roadmap.

I continue to believe that a signal on the start of "waiting a week" would be very useful.

P?ter G?bor wrote

If the bug-tracker's roadmap shows scheduled releases with date in the (far) past

Mantis roadmap features seem to be quite limited (though I am no expert, and if you know better, then please correct me).

1) Lazarus is 1 project, but Mantis shows roadmap for the subproject (patches, packages) too. That pollutes the roadmap/changelog.
2) There is no concept for the SVN revision, (1.5 or 1.4.3) hey show as releases, and must have a date too.
3) All dates must be set 3 times for each of the (sub)projects (times 2 for release and svn)
4) there are only 2 option
a) Released
b) Obsolete

As it is now 1.2.8 does not exist, never did, only it was once planed. It should be obsolete. But in order to do that one must first move all issues that have this version assigned, and give them a new version. (Well it is not a must, but any search that is from version x to version y, will ignore obsolete and there is no way to include.)

This is basically a question of have much time to spent for maintenance there. It is all possible, but we rather try to get something fixed in that time.

The idea is to to a fixes release approx every 2 month, but sometimes it is a bit longer.

I continue to believe that a signal on the start of "waiting a week" would be very useful.

As for full releases there usually are announcements on this maillist before they get done.

Maxim Ganetsky wrote

I would recommend translators to send translation updates for FIXES branch as soon as they have trunk it is enough to send them once a week.

Once a week for trunk is too often in my opinion. New features and their resource strings go through many iterations before they are ready. Translating the intermediate versions would be a waste of energy and time.
For example now there is a new desktops feature. I guess it will still change in near future.

Yes, announcements about dot releases a week earlier would be helpful although texts don't change often in fixes branch. There were some mails in developer list around a week earlier.
Such an announcement would not require a branch for translators.

Juha

12.07.2015 21:54, P?ter G?bor ?????:

The answer is simple: we don't use Mantis roadmap in development activities because we find it inconvenient. See Martin's answer for the reasons.

If you find that there is added/changed string in FIXES branch and you have update for this translation, you are welcome to send it ASAP.

OTOH, if you only improve translation and there were no changed/added resource strings then it indeed makes no sense to send an update after every changed sentence, better will be to see an update every week or after a significant logically related amount of changes.

Keep in mind that as I said before, Lazarus fixes branch translations don't change much at all and I don't consider this issue to be very significant.

That being said, maybe it indeed won't harm to announce minor Lazarus updates for translators to let them catch up.