When the module is used on a site, it is evident, that only code (modules) usable with that Drupal version are present, so the extractor should support that version for extraction. But when used as an API (as in l10n_server), we might need to extract strings from code for different Drupal versions, when asked. So although our running Drupal version might be 5.x, we might want to translate a package for Drupal 6.x, or vice versa.
What complicates this issue is that the extractor sometimes needs live information from Drupal (ie. need to use code from the Drupal version it is parsing code for): the language list and the .info file parsing comes to mind. So we need to have the code to use somewhere in hand.
As it looks in the actual issue, the language list did not change from Drupal 5 to 6, so we can use whatever list function is available. But the .info parser did change, so we can simply include the Drupal 6 .info parsing code (which is a standalone function) and use PHP's parse_info_file() if Drupal 5 code parsing is required.
So basically the parser code in potx.inc needs to be broken out into language dependent and language independent parts (as far as Drupal major versions go) and language dependent parts should be included as required.
Comments
Comment #1
gábor hojtsyAs an overwhelming majority of the code would be shared, I implemented this with a simple version flag on functions where this is required. This is honestly not the nicest solution, but encourages code size reduction and makes potx.inc sharable between the Drupal 5 and 6 implementation which makes later fixes easily distributable.
Comment #2
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.