Module talk:Excerpt/Flow

How does one check which modules are enabled in a MediaWiki instance? How does one install them? I'd expect a link to Module meta-information that has this, but I don't know how to level up in knowledge here.

Hi! This doesn't seem like the right place to ask this but I'll answer anyway: to check if a module is installed in a MediaWiki instance, I think the only way is to visit the page of the module and see if it exists (for example, visit www.yourwiki.org/wiki/Module:Excerpt). If it isn't installed, what you can do is go to a wiki where it exists (in this example, https://en.wikipedia.org/wiki/Module:Excerpt) and copy-paste the source code of the module to your wiki, as well as all the other modules listed as dependencies. Good luck!

Module was renamed to Module:Transcluder and is now fit for Multilingual Templates and Modules.

@Certes: Hi! As you know, I'm moving development here to take advantage of Multilingual Templates and Modules. I think it's the right way to move the Excerpt project forward, as well as the more general Module and Template globalization project. However, globalization seems to be pushing development to some major changes that I'd like to mention, partially out of respect for your original work and vision, and partially so that I may get some feedback from you.

1. I created Module:Excerpt/testcases with an increasing number of test cases. I encourage you to take a close look at it, as it's not only a requirement for globalization, but it's actually amazing and I think it'll soon allow us to speed up and improve development significantly.
2. I created Commons:Data:I18n/Excerpt.tab with the localizations of the error messages. Notice however that a lot of localized data, such as wanted and unwanted templates, doesn't quite fit into this kind of table. I think we may agree that such data cannot live at that table, but should somehow live at each wiki, maybe in a /data submodule, or maybe as a parameter passed on to the module. I actually favor the latter approach, because I think that which templates to keep and which to remove, may vary depending on whether the module is used on portals, articles, etc, and may even require occasional exceptions. A parameter offers the most flexibility without sacrificing convenience, since the default value for the parameter would include the most common wanted and unwanted templates. To tell the truth, I'm not really sure how exactly would all of this look or work, but I hope you see a bit where I'm pointing. What do you think?
3. I created getParagraphs and getFiles methods (see the code or the test cases to understand better what each does, but the names are quite self-explanatory I hope). The goal with these methods is both to offer more options to users with a syntax consistent with getTables and getLists, and also because I'm starting to think that maybe, after getFiles and getParagraphs are sufficiently improved, the current excerpts used on portals can be replicated with high accuracy by concatenating the first file of each article with the paragraphs. If such a replication were sufficient, then the module could be simplified a great deal (the parse() method and maybe others could be deprecated), making it more modular, reusable and simpler to understand and contribute to by future developers. But, do you think the needs of portals can actually be fulfilled with a combination of getFiles and getParagraphs, plus maybe some custom transformations at the /templates submodule?

I think there are other issues to talk about, but I wouldn't like to overwhelm you too much. It may be a while until the code developed here is finally deployed on the English Wikipedia, but I think it'll be worth it. I would most definitely appreciate your feedback on this new direction the module seems to be taking. Kind regards,

@ Sophivorus: I've skimmed through the links, and that looks like a good way to structure things. My interest was in getting something working for portals. I'm not familiar with the requirements for use elsewhere and am happy to see other editors implementing those areas. If all of the portal templates can continue producing the same results that editors have come to expect but no longer calling parse(), that's great. I think the module I created was fit for the limited purpose of portal extracts, but I agree that it benefits from being refactored now that other uses have been discovered. Thanks for carrying on with all the good work. Certes (talk) 14:54, 9 June 2020 (UTC)