I think this plugin should be part of the Joomla main repo to ease testing, but of course it shouldn't be part of the actual release.

Have you thought about TTs? Maybe you should have contacted the Coordination...
If they use Crowdin the strings would be automatically added there (531 for the ini + the sys.ini...) and suddenly disappear unless @Bakual finds a trick.
In any case, as they would work on pre-releases for example with com_localise or with their specific community collaboration tool, the plugin lang files would be present.

Imho, this should not be included in core at any time but made available to install for people testing in a specific github project.

Note: even communities like the French one who do include translated sample data sql in their custom releases, never included a specific testing sample data.
Therefore, if it has to be included in core at any moment, it is not necessary to use ini strings for the contents as they can be hardcoded in English. We would just need basic inis for the title and description.

I'm not talking about deleting and re-adding it on every release. I would keep it in the repo and just delete it from the release package, as we do with lots of other files already.

In any case: We want to make testing simple and right now it isn't. We have a SQL file that last I checked wasn't complete and did not do everything properly and this plugin did not work on 4.0. Also installing a plugin from yet another repo seems to me to be really cumbersome. I understand your concern with the translation, but hope that a file can be excluded from Crowdin or similar.

I understand your concern with the translation, but hope that a file can be excluded from Crowdin or similar.

“To understand a concern” is a politician term usually meaning “whatever you say, I’ll do what I want”.
Sad.

Wouldn't it be possible to add the plugin to the test directory and copy/move it in the test suite?
Would keep the code base clean.

Sad.

"Sad" has become the goto phrase of people who actually want to say "fuck you, I'm not going to budge a millimeter and will not look to find a compromise or a solution for the problem. I will block anything that you bring forward until eternity." Not a valid argument, but I see what you declared above. It is not helpful to the project and not helpful to this issue, but hasn't been the first time that you acted like this.

For all the others out there: I'm happy to incorporate a solution that doesn't flood the translation teams with useless translations, but adding the content to the PHP code directly is out of the question for me. That would make the code unmanageable. If it really is impossible for crowdin to exclude a file, then we have to implement some special method for that and I will say again, that the service is utter crap.
I think it is useful from a testing perspective to have the chance to translate this content, be it just to test our translation system.

Is it not just a case of removing it (or flagging it) in the crowdin.yml

The reason this is not part of core was a decision by PLT at the time. Iirc I had it included in the original PR and then took it out and put it in its own repo
It's simple enough to install in a testing site.
Maybe it could even be added to JED if it isn't already there.

Unless PD decides to include it again, this PR to make it 4.0 compatible should go to the repo of the plugin, not here.

Hannes is not proposing that this be included in the core release. He is proposing that its available in exactly the same situation as the current test sql.

How about getting off your high horses about TT and come up with solutions. Always saying no and refusing to discuss possibilities does you no good and certainly harms joomla

@brianteeman I'm not sure if your response was to me or a general one. I haven't said anything about core release and I haven't said anything about translations.
Actually I think that may be solvable somehow, I'd have to check. But it's not as easy as not adding it to the crowdin.yml. The goal with 4.0 and removing the language file prefixes is that we don't have to manually add each file to that yml file. Crowdin would scan the folder and include all added files. Maybe some can be put on ignore, I haven't looked at that yet.

There would be another issue with the installation SQL which installs the extensions. Easiest would be to nut add it there. The plugin would be included in a nightly but it would have to be discovered. Otherwise you'd have to change that SQL before each release to take the plugin out.

For reference, the PR to remove the plugin from core was #17482, read also the comments in the PR referenced there.

@Hackwar re the last commit "Removing old sampledata install code"

I've not had time to test it yet but I just wanted to flag up that @wilsonge was talking about keeping the ability for a template club (for example) to include a custom.sql in the install

I've added code to remove the testing sampledata plugin from the release package upon building said package.

I also added code to install the testing sampledata plugin when the codebase is in development mode (thus not a released package).

The transitions of articles were also fixed.

Since I had performance issues, I split the article creation into 2 steps, one creating the categories, the other the articles.

The language files are in the plugins folder, they are not in the crowdin.yml. Will this show up in Crowdin? How can we exclude this file?

The old sampledata code wasn't really reachable anyway, so I removed it. I would say that template clubs either have to modify the joomla.sql file or provide their own sampledata plugin.

Dont shoot the messenger ;)

I think I’ve said this before but since I’m accustomed to repeating myself I’ll repeat myself. As long as the localise.sql file is still supported for localized distributions to hook the installer, the mechanism for template clubs is still there just without a UI to choose a sample data file (which, is probably preferable anyway as it’s easier for the user to install without having to make sure they select the right dataset). So, rename the file core looks for to something more generic, document the borderline hidden feature, and there’s your “officially supported non core hack” mechanism. The only limitation here is the same one that exists with the sample data SQL dumps, you’re building on whatever joomla.sql seeds the database with instead of having a clean slate (though to be blunt since you’re already repackaging the Joomla download at that point if this is a problem then just patch the main file and call it a day).

The language files are in the plugins folder.

Should be ok. They will not normally be added to crowdin and would not show in com_localise if parameters set such.

It would be appreciated that a certain lobby (those who write them and those who support them) stop insulting good will volunteers. This certainly more "harms" the project than anything else by pushing people out.

https://support.crowdin.com/configuration-file/#ignoring-files-and-directories ?

I have tested this item ✅ successfully on 8bba2b8

Whatever is said here, at least something has been done about "sample data" and it works.

I've added support for a custom.sql for template clubs or similar to the code.

@Hackwar Please revert the commit regarding Crowdin. It's not needed.

OK So we now have my long desired custom.sql file to allow template clubs to do things whilst keeping localise.sql free for language packs (and those things can obviously be combined if desired). If custom.sql exists it will be used I believe this addresses concerns @ciar4n raised (amongst other template devs) about moving the sample data stuff into plugins.

We have excluded this file from crowdin explicitly which means that our crowdin users will not be affected by this move (and addresses @infograf768 's comments). @Bakual I asked for this so it was explicit in the future rather than people thinking it might be a bug even though your right technically as it's not on the list it would be ignored anyway.

It's been clear to me for a while that people aren't using the sample data plugin after it was decoupled as there were long periods where things like com_contact was totally broken and no one noticed (where as in 3.x this has been picked up faster because of the data being there). So I'm actually much happier re-integrating this for people installing from git.

Awesome stuff. Once it is merged I can take a closer look and make sure we have test data for things like custom fields and other new features

@wilsonge I think the idea to decouple it was actually fine. But I agree it wasn't used anymore. However there would be other ways to let it install easy again (eg using JED) than adding it back to core.
It would also be easier to translate and develop it independant of the core (eg testers could tranlsate it themself - no need for official TTs here)

It's a pity the decoupled extensions get almost zero attention and this PR seems to be needed.

I agree in principle it was fine. But practically if it's not working out then it doesn't really matter how good the idea is :)

I didnt even know there was a decoupled extension

The plugin did not work in 4.0. last commit was from 2 years ago.

I didnt even know there was a decoupled extension

The plugin did not work in 4.0. last commit was from 2 years ago.

That's basically what I meant.
Same as with weblinks and the future com_search, decoupled extensions get no attention anymore.
Maybe a more prominent advertisment (eg in the JED installer) for those extension would help raise awareness so Brian and other testers would have known about it.
For the 4.0 issue, Hannes (or another developer) obviously should have done the PR on that repo to get it working.

It's an issue we need to solve for all those extensions, except if we use those repos just as an excuse to throw something away.

I'm not using those repos to throw stuff away and I plan to improve the visibility of these extensions from the point of the ATT in the future, but we can't do magic and it will take some more time.

Our extensions need automated tests which run regularly against the Joomla codebase and throw a tantrum when there is an error. I hope to start work for this before 4.0 is released.

But in this specific case, I do in fact think that this belongs into core. It is an absolute integral part of our testing and I think we need to make this as easy as possible. Right now it is 2 clicks to install the testing sample data. If we require you to download it first either from github or from JED, then that would require at least 6 clicks to install it and then another 6 clicks to enable it plus yet another 3 clicks to install the sampledata. So 2 to 15 clicks. If you have to do that for every 5th issue in our tracker, that would mean that 2 people testing everything twice would need to do that 180 times times 13 additional clicks... You get what I'm saying.

Long story short: It is a matter of makeing testing simpler and for that I would want to see this as part of core.

Thanks!

Thank you!

Unfortunately the plugin doesnt really work - see #25777