Yes it is often redundant.

The problem is that it would mean a lot of changes and each time there are
a lot of changes the translators and certain plt are up in arms and I am
not personaly prepared to go through that again.

For reference it is 300+ strings.

I can make the change if PLT support it

IMHO, @ot2sen's proposal would be an improvement if accepted.
+1

Thanks @brianteeman it would be a nice adjustment if the PLT understand the impact changing this relatively few strings to a cleaner source basis.

An extra thing to have in mind is that the en-GB source files act as educational/best practice way of composing strings. This means that extensions developers, most often non-English, would inherit the use of 'successfully' and the use of it spread quickly. Setting a different standard in core source files would help on limiting external use too.

That is exactly what I have said for years but sadly that view has not been shared

Whilst @ot2sen is technically correct to say that "successfully" is redundant, it is certainly not wrong to use the word in that context. Personally, I don't mind either way. If you feel strongly that it is worth the effort then I won't object.

The effort to create the PR is minimal

I think it's important to have a correct English language file.
When we translate stuff into Dutch we use the correct Dutch sentences and even when the English use Successfully Saved we use Saved.
I hope everybody agrees to make this change.

Btw. the same as for dutch applys to the german language files.

As I said once the plt agrees I will do the pr

? Useless change (quoting @chrisdavenport : "it is certainly not wrong to use the word in that context.") that will force all TTs to check what has been changed for 302 strings.

Indeed a specific language does not have to use the en-GB wording, but crowdin and com_localise will mark these strings as modified and force all to spend a few hours on this, even if they decide to keep the original translation.

It would be OK if the en-GB value was wrong. It is not in this case.

It's amazing to see how some that do not make the registered language packs are prompt to give more work to other volunteers.

And that's why we can't have nice things

but crowdin and com_localise will mark these strings as modified

If we do merge this, we can update Crowdin so it doesn't disaprove the translations. Just needs a bit of coordinating between merging and running the Crowdin sync script.
Com_localise is a different topic of course. I don't think it can be handled there.

It would be much easier if all would use the same tool and process for translation. Does anyone knows how many translation teams are using Crowdin?

I don't know for sure, but looking at https://crowdin.com/project/joomla-cms you can have a guess based on the languages which are almost translated/approved. At the moment we have

• 12 fully translated/approved languages
• 2 fully translated but not fully approved languages
• 15 languages translated over 90%

My guess would be those are the ones actively using or at least testing it.

and 23 languages that never managed to update to 3.5

On 1 July 2016 at 13:55, Thomas Hunziker notifications@github.com wrote:

I don't know for sure, but looking at
https://crowdin.com/project/joomla-cms you can have a guess based on the
languages which are almost translated/approved. At the moment we have

• 12 fully translated/approved languages
• 2 fully translated but not fully approved languages
• 15 languages translated over 90%

My guess would be those are the ones actively using or at least testing it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10971 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPH8RcRqkVtPpt-AR-K77IDDsy0AMHmks5qRQ5agaJpZM4JBhvS
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Set to Needs Review so the PLT can make a decision and not waste anyones time

I just would like to add that IMHO, asking today who is using Crowdin is not the question since NO communication was made to explain and encourage translators to use a platform 100% dedicated to L10N.
Once again, and "playing" with more than 20 diff t9n platforms per week, AT THIS point, Crowdin is ahead ON A TRANSLATOR (those who are the most to work with) point of view.
With a bit of promotion, it is possible to EASILY output projects with more than 30 languages in less than 2 months (eg the 3.5 landing page or soon the issueTracker).
As with many type of management, managing translators is a job, a real job, and not only a tech one.

As stated before I am happy to do the Pr. But its not just a simple search and replace so I'm not going to waste my time if it will be rejected as "too much work" for the TT (an argument I for one am sick of hearing)

Agree but IMHO we really must take an additional leap forward even if it means more work even for translators.
Sometimes, having a specific task is also a way to gather new volunteers if we call for them the right way.
I'm ?

@bakual yes or no. If no then this can be closed. If yes then I will make the Pr

Imho, the PR can be done. The question is more if it should be merged into 3.7.0 (will probably be close to language freeze) or better shortly after release.
As said, if coordinated it can be done without an impact on Crowdin, but all other tools (com_localise, manual diff) will show a ton of changed strings.

OK I will do it and then you can decide when to merge it - probably after
3.7.0

On 14 March 2017 at 11:58, Thomas Hunziker notifications@github.com wrote:

Imho, the PR can be done. The question is more if it should be merged into
3.7.0 (will probably be close to language freeze) or better shortly after
release.
As said, if coordinated it can be done without an impact on Crowdin, but
all other tools (com_localise, manual diff) will show a ton of changed
strings.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10971 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8XlpN850Gw0QwUfyaxBaNP-gQJRoks5rloDwgaJpZM4JBhvS
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

merci with success!

Can be closed as there is a PR