Your short window of 24 hours will never be workable (or it will simply exclude most translators that cannot be tied to this very strict schedule) it is even worse than the 3 days delay we have now (which is in fact already shorter, due to the time needed just to receive the notification : I've already received notifications for announcements that were supposed to occur 3 days later, but whose deadline was already passed since a few hours !).

After all these weekly updates come after weeks (if not months) of developments and testings, and these translations should be announced and prepared long before, during the development, so that these translations would be ready long before the weekly updates announcements.

In other words, we should ask to developers to request translations before, even if this is just for an early beta and that some translations will change several times, but at least the essential would be ready with less to translate for the last phase before launch.

2013/6/10 Guillaume Paumier <gpaumier@wikimedia.org>

It's a difficult choice to make. On the one hand, we would ideally
want as many translations as possible, so a week of lead time would be
better in this regard. On the other hand, most of the content of the
tech newsletter becomes outdated very quickly, and would be mostly
useless if sent a week later.

I'm open to suggestions about how to facilitate translations while
sending information to subscribers before it becomes outdated.

One possibility that I'll try to adhere to as often as possible is to
have a very predictable schedule, meaning for example that the
deadline for having the newsletter ready for translation should be
very strict. That way, translators would know that every week, there
will be a window of 24 hours for translation, and the window will
always be the same each week. I think more predictability would help
facilitate translations.