Change Details

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: * [x] `LanguageCode` * [x] `MessageLocalizer` * [x]`ConverterRule` * [ ] `LanguageConverter` * [ ] `Language` * [x] `FakeConverter` 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?

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: * [x] `LanguageCode` * [x] `MessageLocalizer` * [x]`ConverterRule` * [x] `LanguageConverter` * [x] `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?

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: * [x] `LanguageCode` * [x] `MessageLocalizer` * [x]`ConverterRule` * [ * [x] `LanguageConverter` * [ ] `Language`` * [x] `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?