? ? Pending

User tests: Successful: Unsuccessful:

avatar brianteeman
brianteeman
5 Jan 2018

Its a decoupled extension. We dont need to ship it in J4. The only reason it stayed in J3 was for translation workflow but even that has been suggested to cause problems as the component is not on the same release cycle etc. See #16753 for discussion

[note i have not removed it from the toc.json as the helpTOC.php script is broken

avatar brianteeman brianteeman - open - 5 Jan 2018
avatar brianteeman brianteeman - change - 5 Jan 2018
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 5 Jan 2018
Category Administration Language & Strings
df2e9be 5 Jan 2018 avatar brianteeman oops
avatar brianteeman brianteeman - change - 5 Jan 2018
Labels Added: ? ?
avatar Quy Quy - test_item - 5 Jan 2018 - Tested successfully
avatar Quy
Quy - comment - 5 Jan 2018

I have tested this item successfully on df2e9be


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19307.

avatar infograf768
infograf768 - comment - 6 Jan 2018

Until we have a full solution for TTs to include these lang files into their packs or fetch these lang files in a way or another, I disagree to take them off from core.
There is nothing urgent which needs this PR to be merged.
One does not put the cart before the horse

avatar brianteeman
brianteeman - comment - 6 Jan 2018

The point as expressed in the discussion is that the TT do not need to (nor should they) add the translation into their packs. Thats why it is decoupled. As stated in the discussion keeping the translations in the packs ties the release of the uncoupled extension to the releases of joomla which is not desirable.

avatar infograf768
infograf768 - comment - 6 Jan 2018

I perfectly understood that and also that we do NOT have yet a solution for that.
As I said, let's not place the cart before the horse, please.
When a solution will be proposed for the process, it will be time to merge this PR.
Until now, we do not have any and that is why the strings are presently kept in the pack.

avatar brianteeman
brianteeman - comment - 6 Jan 2018

I would counter that until the TT are forced to make a solution then nothing will happen and we will be stuck with these useless strings until joomla 5

avatar infograf768
infograf768 - comment - 6 Jan 2018

The problem cannot to be solved by TTs. They are not developers or joomla sites maintainers. I am sure they will accept any easy solution.
This should be easily understood.

avatar brianteeman
brianteeman - comment - 6 Jan 2018

The TT leaders are though and they are more than capable of coming to a solution but clearly the evidence shows that until they are forced to do it then they wont

Merge it or not but lets not keep the translation process in closed silos that are stagnated and hold Joomla back

avatar Bakual
Bakual - comment - 6 Jan 2018

Sorry, but that is indeed not something that has to be solved by the TTs. It's something which has to be decided by the maintainers of the weblinks pack how they want the translation files distributed.

avatar dgt41
dgt41 - comment - 6 Jan 2018

Isn’t already decided that j4 will use one common platform for the translation?

avatar Bakual
Bakual - comment - 6 Jan 2018

Isn’t already decided that j4 will use one common platform for the translation?

Yes, OSM has apparently decided that Crowdin is the "official" tool for translations. Whatever that means in details is open.
But the main point isn't about how to translate the files (that is something TTs can figure out indeed). Someone needs to decide how they are distributed. Eg should weblinks translations still be part of the official language pack. See the original issue for the details.

This PR is certainly needed at some point, but it is only one part of the issue.

avatar infograf768
infograf768 - comment - 6 Jan 2018

@dgt41
It has indeed be decided so without talking with the TTs and its coordination. Still to be discussed.
But, in any case, even if that was the final decision it does not solve the issue by itself.

For core we use a cron job picking the packs (for the moment from joomlacode) which proposes an update for language files when the pack is modified.

In the case of a decoupled extension like weblinks, it is much more complex.

  1. Weblinks, should be installed. This should be checked.
  2. The update for weblinks language packs may or may not depend on the weblinks version
  3. We may have to define a way to update these packs (if they are packs), therefore also check if the concerned core language is present or not.
  4. Or the language files may have to be present in the weblinks extension folders (we have >60 languages for now for core) and distributed at the same time as weblinks is updated, therefore a totally different schema than core, i.e. no possibility to get a new language for weblinks until it is updated or corrected.

As I said, there was a good reason why, until now, we kept these files in core as we have NO process defined to cope with these issues.

avatar dgt41
dgt41 - comment - 6 Jan 2018

@infograf768 isn't weblinks something similar to any 3rd PD component? If 3rd PD have already solve this problem why aren't we just copy the best practices out of their workflows, do we have to reinvent always everything?

we have >60 languages for now for core

We can delete (post flight) the unneeded languages

no possibility to get a new language for weblinks until it is updated or corrected

I haven't really followed the discussions for the languages changes, but I would guess that the translation would be better and more efficiently coordinated and thus this could be eliminated

avatar Bakual
Bakual - comment - 6 Jan 2018

If 3rd PD have already solve this problem why aren't we just copy the best practices out of their workflows, do we have to reinvent always everything?

Have you read the original issue? Because those points are explained there. No point discussing the same things here again.

avatar brianteeman brianteeman - change - 3 Apr 2018
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2018-04-03 18:54:01
Closed_By brianteeman
avatar brianteeman brianteeman - close - 3 Apr 2018
avatar rdeutz rdeutz - change - 3 Apr 2018
Status Closed New
Closed_Date 2018-04-03 18:54:01
Closed_By brianteeman
avatar rdeutz rdeutz - change - 3 Apr 2018
Status New Pending
avatar rdeutz rdeutz - reopen - 3 Apr 2018
avatar laoneo
laoneo - comment - 4 Apr 2018

My point here is that we need to have a clean core. Language files of decoupled extensions need to be removed. If our language process is not ready for that, then we need to fix it, and not put that burden on the core.

avatar brianteeman
brianteeman - comment - 4 Apr 2018

The real point is that clearly unless they are removed from core then no one will make sure that the language process is adjusted to cope. There clearly is no interest for anyone to do that until they are forced to. Just go ahead and merge it and then it will have to be done!!

avatar Bakual
Bakual - comment - 4 Apr 2018

@brianteeman No, that's not the point.
I have actually two PRs open which would start the process and help getting toward a solution.
joomla-extensions/weblinks#383 and #19353.
But someone (not me) needs to make decisions and either merge or close the PRs. Otherwise we will be stuck forever. Just deleting them doesn't solve anything.

avatar brianteeman
brianteeman - comment - 4 Apr 2018

delete them here and forces that "someone" to make a decision. Pretty sure we all agree they shouldnt be here - the issue is just where/how

avatar mbabker
mbabker - comment - 4 Apr 2018

As the weblinks repo is dead yet again, and I've already made it a point to say #19353 is a good idea (unless you're someone who has language resources of several languages in one directory where adapting to that forces a workflow change on your end) I don't see what the roadblock is to moving forward other than people being unwilling to do so.

avatar brianteeman
brianteeman - comment - 4 Apr 2018

so merge it then please. I cant merge my own code

avatar mbabker mbabker - change - 4 Apr 2018
Status Pending Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2018-04-04 13:32:18
Closed_By mbabker
avatar mbabker mbabker - close - 4 Apr 2018
avatar mbabker mbabker - merge - 4 Apr 2018
avatar infograf768
infograf768 - comment - 4 Apr 2018

I see it is useless to explain issues. Thanks for not taking into account multiple oppositions to this PR until some aspects of proposing specific language packs by TTs is solved.

avatar mbabker
mbabker - comment - 4 Apr 2018

Since 2013 nothing has progressed as it relates to managing translations of decoupled extensions (first Install from Web, then Weblinks). If this forces the status quo to be challenged and some kind of action to come out of it, then for the first time in 5 years progress will have been made.

Add a Comment

Login with GitHub to post a comment