Locale module uses an array to store data of translatable projects and available translations during its translation update batch processes. Also different (helper) function are used to process the project related data. Readability and maintainability of the code could be improved by combining functions and data storage in a TranslatableProject class and by using a typed class to store the translation source file data. This was suggested by Berdir in #1804688-14: Download and import interface translations. This gives the opportunity to simplify the way the $source data is handled within the batch operations.
| Comment | File | Size | Author |
|---|---|---|---|
| #44 | locale-project-translation-object-1842380-44.patch | 100.99 KB | sutharsan |
| #44 | interdiff-1842380-43-44.txt | 87.65 KB | sutharsan |
| #43 | locale-project-translation-object-1842380-43.patch | 93.43 KB | sutharsan |
| #36 | interdiff.txt | 40.1 KB | skipyT |
| #36 | locale-project-translation-object-1842380-36.patch | 92.33 KB | skipyT |
Comments
Comment #1
sutharsan commentedTagging for extra attention ;)
Comment #2
gábor hojtsyShould this not be based on Update module representing projects with a class instance first and foremost?
Comment #3
gábor hojtsyI think this should be postponed on introducing project classes themselves, no? That is #1832946: Runtime translation download fallback works different from installer translation download fallback.
Comment #4
sutharsan commentedAgree
Comment #5
sutharsan commentedSharing my ideas of how to improve the readability and maintainability of the code by aggregating the project translation state and helper functions into one class. The patch is build on top of #1998056: Automatically update interface translations using cron #25 and therefore quires that patch to be applied first.
Comment #7
jair commentedComment #7.0
jair commentedUpdated issue summary.
Comment #8
aks22 commentedComment #9
aks22 commentedThe patch file which i was applying is not there.
File path:
/core/modules/locale/lib/Drupal/locale/ProjectTranslationState.php
also checked on git.
Comment #10
aks22 commentedThe patch file is for core/modules/locale/lib/Drupal/locale/ProjectTranslationState.php
which does not exist in core module.
Comment #11
sutharsan commentedThe patch needs to be rerolled first. See https://drupal.org/patch/reroll for instructions.
Comment #12
akozma commentedRe-roll.
Comment #13
akozma commentedComment #15
akozma commentedre-roll
Comment #17
sutharsan commentedUnassigning @akshay.swnt2. If you are still woking of the issue, please tell us here.
Comment #18
skipyT commentedAfter discussing with Sutharsan I'm proposing the next solution:
- we wait until #1842362: Replace locale_project table and improve caching will be committed
- we rewrite the interface for the project storage to return TranslatableProject instances
- we rewrite the interface for project storage to save TranslatableProjects inside the key value store. We can create a toArray() method on the translatable projects class.
- we'll store the translation status for each project inside the TranslatableProject data, this means it will be saved with the other project data in the key value store into the locale.project collection.
I propose also the following class names:
- project storage: LocaleProjectStorage
- translatable project class: LocaleTranslatableProject or just TranslatableProject
Comment #19
sutharsan commented#1842362: Replace locale_project table and improve caching was committed. Lets get this one rolling again ;)
Unassigning akshay.swnt22. This is not personal, but is has been a long time and I like to clear the path for anyone (incl. myself) to pickup the issue.
Comment #20
skipyT commented@Sutharsan: I could help also. you can contact me on IRC to discuss about this. my nickname is: skipyT
Comment #21
sutharsan commentedWorking on rerolling the patch. Major changes in the status form...
Comment #22
sutharsan commentedRerolled the #15 patch, but did not make changes to TranslationStatusForm.php. The code of the form changed significantly and I doubt that the status form changes in #15 will survive. Because I don't want to spent a lot of time re-rolling code that will not be reused, I dropped it in this re-roll.
Comment #23
sutharsan commentedThis is the implementation of the ideas described in #18. Code is partly working, test not yet tested. The interdiff is perhaps too big to be useful.
Comment #25
sutharsan commentedMore working code. Completed interface documentation. Can't get the tests working locally (even on 8.0.x, without patch), so no warranties on tests.
Comment #27
sutharsan commentedMade test working. Some LocaleTranslationProject methods renamed.
Comment #28
sutharsan commentedGo botty
Comment #31
sutharsan commentedComment #32
skipyT commentedHi,
I read your patch and I have some ideas how could we improve the patch. But I need some time to reflect on it.
My concern is with that source object returned as a stdclass. Perhaps we should somehow split this class into 2 separate classes and try to have classes doing only one thing.
Also some methods are not unit testable, like the update method. I will try to push a patch until tomorrow morning to propose a new, cleaner class hierarchy here. I wanted to do it for yesterday, but it took me a while understanding the whole code.
Comment #33
sutharsan commentedLast week I discussed in IRC with SkipyT some possible improvements:
use
$project->getSourcebyLangcode($langcode)->getRemoteSource();Comment #34
skipyT commentedI tried to rewrite the LocaleTranslatableProject to a new class hierarchy. Now I have:
- LocaleTranslatableProject
- ProjectState
- AbstractProjectSource
- LocalProjectSource
- RemoteProjectSource
This is a work in progress, I uploaded it only to have an early review. I will continue to work on this. I need to create the class interfaces, to clean the code, to have the right comments.
Comment #36
skipyT commentedI continued the work on the patch from #34.
Comment #38
skipyT commentedrerolled the patch.
Comment #39
skipyT commentedComment #41
sutharsan commentedI've discussed at DC Amsterdam, with skipyT how to proceed.
Some code examples as we would like to retrieve the source data.
Comment #42
sutharsan commentedWorking ...
Comment #43
sutharsan commentedFor the record, #38 rerolled.
Comment #44
sutharsan commentedThis patch is partially working. The OO architecture is complete enough for a review. I'm not sure if I have the time to continue working on it the following days, therefore I share what I have now.
Summary of changes:
Still to do:
Comment #52
nterbogt commentedIs this something that is still on the cards? I'm having all sorts of performance issues with this specific part of locale.
I have 157 custom languages, only 7 of which exist on the Drupal translation servers.
Comment #61
berdir12 years later: We're finally making progress on modernizing and cleaning up locale.module. Some existing issues and currently #3566536: [meta] eliminate core .module files are introducing a LocaleTranslatableProject class but after the most recent changes again only for $project and not $source, which is slightly different. Rescoping this.
@nterbogt: It's been many years since your comment, but #3586654: Avoid scanning the file system for local po files is a related recent issue that seems to significantly improve performance with many languages. There's also discussion on performance in #3037156: Modernize locale history functions.
Comment #62
berdir#3590050: Deprecate and replace locale_status related functions introduces LocaleTranslationSource now and also cleans up the translation status functions. I think that's the last major step of #3215707: [META] Modernize Locale module, there's still a good amount of work left before we can close that meta, but after that, it's it's mostly just a bunch of relatively simple helper functions.