Re: Some question and suggestion about language files
Posted by skenow on 1219001930
What if we were to load the english file first, then the other language, simply replacing any existing defines with the new language? In that way, if the translated language doesn't contain a certain constant, it at least is present because the english version was loaded.
As you say, it would mean loading both files - which is extra work for the server. I'm not sure if defines cause conflicts if they are redeclared.
Andy - we aren't ignoring you, we're just taking it in a little different direction.
The problem is, the version numbers within the files are not chosen manually - they are updated when changes are committed to SVN. If I make 2 changes to the english file, that will increase the version number by 2. If I also make a typo and commit again to correct it, the version number will also increase, but have no impact on translation. If you were to take those 3 commits, make all the necessary changes to the german version and commit the changes all at once, your version will only increase by 1 and our version numbers no longer match, but the files do match.
Or, if you were to create a new translation from an existing english language file that has had many revisions, you would do your translation and commit at once, rather than follow the same commit pattern as the original.
The language files should have releases, just like the core and modules and I think we have established this pattern already. McDonald's practice of having separate sections in his language files certainly sounds like a good one to model. The language_changelog in the core is designed to consolidate all the changed throughout the core in one place.
Any ideas for improving on this are certainly welcome
As you say, it would mean loading both files - which is extra work for the server. I'm not sure if defines cause conflicts if they are redeclared.
Andy - we aren't ignoring you, we're just taking it in a little different direction.
The problem is, the version numbers within the files are not chosen manually - they are updated when changes are committed to SVN. If I make 2 changes to the english file, that will increase the version number by 2. If I also make a typo and commit again to correct it, the version number will also increase, but have no impact on translation. If you were to take those 3 commits, make all the necessary changes to the german version and commit the changes all at once, your version will only increase by 1 and our version numbers no longer match, but the files do match.
Or, if you were to create a new translation from an existing english language file that has had many revisions, you would do your translation and commit at once, rather than follow the same commit pattern as the original.
The language files should have releases, just like the core and modules and I think we have established this pattern already. McDonald's practice of having separate sections in his language files certainly sounds like a good one to model. The language_changelog in the core is designed to consolidate all the changed throughout the core in one place.
Any ideas for improving on this are certainly welcome
This Post was from: https://www.impresscms.org/iforum/viewtopic.php?topic_id=2228&post_id=21263