| | 24 | |
| | 25 | |
| | 26 | == Planned Implementation == |
| | 27 | |
| | 28 | * Removal of Deprecated Strings : Size of “.py ” files will keep on increasing if the new strings are merged with the existing strings. As changes are made to code some strings become deprecated while some new strings are introduced. So we can run the code with all the modules selected periodically and replace the existing files. This will remove all the deprecated strings and new strings will be available for translation. This can be done by using the “-o” option in the existing translation module which will overwrite the existing “.py” files instead of merging with them. This can be made into a scheduler job which can run periodically or it can be manually triggered by the admin as and when appropriate. |
| | 29 | |
| | 30 | * Retrieval of strings from currently active template : Currently, we don’t have an option to check which strings are present in the active template. This can be done as follows: |
| | 31 | * Use the parse tree approach to parse out the currently active template from 000_config.py |
| | 32 | * Next, we parse the eden/private/templates/<current-template>/config.py to get the active modules of that template |
| | 33 | * So, only these modules will be checked by default (when showing the module selection page) |
| | 34 | * Hence, we know which modules correspond to the current template and this can be used to extract only the relevant strings. |
| | 35 | |
| | 36 | * Including database variables : We need to extract the strings in database variables so that they too can be translated. Currently, these variables are excluded from translation. Hence, one approach to extract these strings is as follows: |
| | 37 | * Use the prepop csv files in privates/templates/<current-template> and mark them to be considered for translation. |
| | 38 | * Provide a “Select all templates” option on the module selection page (similar to select all modules) to specify if all prepop files are to be considered. This option will be helpful when introducing new variables and discarding deprecated strings using the overwrite option as mentioned earlier. |
| | 39 | |
| | 40 | |
| | 41 | * Pootle Integration : We need to make sure that the translation in pootle is kept in sync with that in the “.py” languages file. Below are few points to help us achieve this : |
| | 42 | * As and when we use the overwrite option to remove deprecated strings,(as explained earlier) reflect these changes in pootle too. This will ensure that pootle doesn’t have any old strings and that new strings are also added. |
| | 43 | * When merging from pootle, we might receive some conflicts ( just as through pull request). One possible solution is to create a script that identifies and stores all such conflicts in a file which can then be manually handled by translators. |
| | 44 | * Also, an option for uploading ".po" files will be provided (apart from the current ".csv" files). The conflicts arising when merging this can be handled as mentioned before. |
| | 45 | |
| | 46 | Hence, the translations in pootle and web2py will be consistent. |
| | 47 | |
| | 48 | * Version Control : There can be a scenario where the translated strings received through pull request conflict with what’s already in the repository. Hence, we have to prevent this merge conflict. This can be handled in the same way as for Pootle (manual intervention). |
| | 49 | |
| | 50 | * Avoiding External Dependencies : Current code makes system calls to csv2po and po2web2py but we want to remove these external dependencies. The link below gives a good reason why we should avoid this. |
| | 51 | |
