You, or anyone are free to take a task as a language coordinator at any time, instead of demanding others to do it. We could also ask someone politely to do it, instead of naming it stupid etc.

Well said.
But also I have written that I will be more than busy with other tasks until the end of January (maybe you heard of important law changes in Austria from the 1.1.2016 .. ?).
Because of that, I am sorry that I have no time for anything else.

We 3 are 'managers', but none of us has a role like a 'leader'.
But one should be, otherwise 3 'spoons' will make the 'soup' salted .. (or as it can be in English ..).
And I never said that another should do it, only said that one should take over / do (that could be also me if I have time again).

Fixed the username B/C https://github.com/arastta/arastta/commit/27906c082c61b73d62121ea871bf6bbec39dd19b

Sure Rune, release leader must notify the translation managers about the timeline. Will make this happen for the next releases.

the strings in install are not required anymore

Unless someone, for some reason, still wants to install 1.1.5 - but I agree, not important to keep those as they normally would be in that pack already.

Btw! Could the release leader for each release post a heads up to the Translation Management Team, when a new release is planed in the future please?

Rune, the strings in install are not required anymore but the ones in user must be there, you're right, thanks

Currently we have 3 Language Managers; Michael, Rune and Gilbert. You guys can open a discussion in the Translation Management Team group and assign a member to this taks: http://arastta.org/community/groups/item/11-translation-management-team

Also, please, be polite when complaining otherwise it doesn't help.

But why must I hightlight such 'stupid' task?

This is the root of the problem, how you express things. You write like you're there.

You, or anyone are free to take a task as a language coordinator at any time, instead of demanding others to do it. We could also ask someone politely to do it, instead of naming it stupid etc.

Edit! And there has been a lot of backward compatibility breaking also in Joomla, as in all software. At some point it has to, to avoid bloating. Now a days it's tried to be kept for major releases, like between 2.5 and 3.x - but sometimes shit (mistakes) just happens anyway.

Btw! How do you really think JM did know what was changed? Think of it for a minute or two. Yes, he monitored and compared manually for a long time, for free.

No sorry, I am not in a angry corner.

But why must I hightlight such 'stupid' task?
Arastta aims to be new and professional shopping system.
Fine.
But then we should not forget taks like that.
And every minute someone else is searching for changes while the person who did it knows that exactly - is for me 'wasting' time.

For example (and you should know that) Jean Marie of the Joomla Translation Team sent us always early enough all changes for translating .. early enough.
Here a new version is published .. and nobody is informed about langaueg string changes.

And as you mentioned above, removing strings from the current file will break the backward compatibility.
Fine - or what?

What will you call that?

As long as nobody is responsible for languages (call it Language Manager, call it somewhat), as long it will be not working.
Enough written from me in this case.

Adding, changing, removing language strings, vars, values should be always done by that person who is merging the PR.

Sorry Michael, but you seem to be in the "angry corner again". And I really don't understand why, but it's counterproductive...
Doing a diff take less than a minute, uploading the new and changed files less than a half hour I believe. I'll f... do this, this time, instead of wasting time yelling on each other here.

@Denis.
There is 6 new, and 24 changed language files. In this it's mostly new defines and changed strings, but there is 4 removed defines/strings (username), which would break backward compatibility for the language packs (they gets removed from Crowdin when uploading the changed files). They should probably have been kept to keep backward compatibility, and rather commented for later removal in a major version as it seems quite unnecessary to have two language branches at Crowdin just because of those 4. Could we add them back to avoid this?

Ref.
https://github.com/denisdulici/arastta/commit/30b1b1dc1326042c35f468003a27585b79531d4b
https://github.com/denisdulici/arastta/commit/65c8c25f7a3211e9e7de64b158915eee4949f3e3

When I write adding, changing, etc. .. by the person .. I mean the person who is doing that task!
Nobody else can know what has changed.
And nobody else should waste his time to find all changes (even not with tools like e.g. Winmerge, etc.).

So maybe you misunderstood me.

Where and at which workflow?
A simple text or php file should do that job.
Otherwise if Github can support such, it would maybe better.

But in any way how it is done, WHO will manage all that?
Who will then add the files to Crowdin?

That are my suggestions, and my critic as well.
Same easy as telling what is wrong.

But anyway, if wrong right or something else .. it has to be mentioned AND discussed.
No matter how busy who may ...

And NOT talking about is the much worst case - as it was until today.
Or did I see some of one of you?
I do not like to post only 'small-talk' or 'bla-bla-bla' and I am doing not the 'fine american way' ... (lile 'Nice to see you' but meaning 'Better you leave me').
I prefer to say what is fact - and if I am wrong, everybody can tell me that and there is no reason for nobody to be angry!

[forgot before]
The moment a new release is planned, also the language changes should be announced early enough internally!
To give translators the change - early enough - to start their job.
Have I suggested enough?

Adding, changing, removing language strings, vars, values should be always done by that person who is merging the PR.

Why? That means adding, changing, removing all the way. Especially for removing it's not good, as it breaks backward compatibility.

Anyhow we are all busy. So please add your suggestion on what workflow you prefer and need from the start, easier than just telling what's wrong - and also it's easier to discuss then.

Auto-sync based on tags/branches is probably the best, but that requires someone writing it.

We already had such a label but not used yet. I assigned it to the related PRs and Issues.

There is yes ...

Sorry Rune, nothing against you!

But - I am currently more than involved in other projects, therefore I cannot check yet what has changed,w aht is new, what has been removed!

Adding, changing, removing language strings, vars, values should be always done by that person who is merging the PR.
The idea with the labels is good - but how to get to the changed variables?
And someone must commit / add them to Crowdin.

It makes no sense in a mulitlinguale project to change language vars/values and nobody get aware of them - or will see it when he opens the shop/backend.

So, could we please find a easy way for communication?!

There is yes, and also there has been some before too, not being added - so we need to find a proper workflow here.

A good beginning would be to add a tag, for commits including language changes. Not sure how it's done, but it displays and can be filtered at t.ex. https://issues.joomla.org

Btw! Crowdin also support versions (branches/tags) now I belive, in case there is need for removing/rewriting strings for new major releases.


Edit! It's named labels (not tag) at GitHub: https://github.com/joomla/joomla-cms/pulls?q=is%3aopen+is%3apr+label%3a%22language+change%22