The code being split between includes/ and languages/ can be confusing at times and as part of T166010 this would be expected to change regardless.
This task is to start thinking about that specifically for the languages/ directory:
- How we want to organise it going forward?
- What (if anything) external to MW would need to be updated? Due to these classes having been in this place for a long time, it's possible various (automated) workflows might have come to depend on their precise location.
- What do we want to do with files that cannot be autoloaded?
Easy ones
The following are presumably easy candidates to move over without much complication:
- LanguageCode
- MessageLocalizer
- ConverterRule
- LanguageConverter
- FakeConverter
- Language
These could go to includes/language/, alongside the Message class which is already on the "includes" side.
Data files
The data files (those that do not declare functions or classes, but rather return data or export local variables) could go to includes/languages/data similar to what various other sub directories do already (such as includes/collation/).
Language sub classes
These could move over now as well. Or should we keep out of includes/, for proximity with non-code files in messages/ and i18n/ files?
PHP Message files
These are neither clean data files, nor autoloaded classes. They are files that declare local variables in a to-be-included local scope. This is pretty hacky and might be time to convert to a simple static array file that returns these as keys. This should also make the reading of these files much easier to deal with.
Misc files
- CrhExceptions
This is organised like a data file, but is actually a class with methods. Unsure where it should go.
- Names.php and ZhConversion.php
An autoloaded class file, but stored in the data directory and uses "data" as actual part of its class name hierarchy as well. (For other components in "includes/" the data file is usually associated with files that are not in the class hierarchy but related to the files nearby). Having the class hierarchy overlap with a "data/" subdirectory might be confusing. In particular, after the PSR-4 transformation this would currently cause there to be two directories that only differ by case-sensitivity (includes/Language/Data and includes/Language/data). That's probably something we want to avoid.
Maybe we'll rename all "data" subdirectories that contain non-class to "Data" to accomodate this issue. Or maybe this could be renamed something that doesn't have "Data" in its namespace path (with back-compat alias). Or something else?