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
I will try to show you what i mean, i´m sure it gives a reason for that, what i report:
1. I download direct from smartsection the wfdownload module, include the english language files. The id or version and when the system gives that number, one after next, i (and i´m sure i´m not the only one) had the following problem:
1.1 $Id: admin.php,v 1.24 2007/06/25 15:57:52 m0nty_ Exp $
2. I downoad over impresscms, but there are two versions on the module and containe the following english language file:
2.1 $Id: admin.php,v 1.19 2006/05/25 14:13:55 m0nty_ Exp $
2.2 Remember, i my entry topic i report the following english language file number:
$Id: admin.php,v 1.23 2006/11/05 16:14:36 m0nty_ Exp $
3. I download the german langauge file from smartfactory for the wfdownload module 3.2rc1 with the following id or version number:
$Id: admin.php,v 1.19 2006/05/25 14:13:55 m0nty_ Exp $
Let us say, i will help to translate or edit the german language file for this module. Which version is the newest and if the newest file the file with the last changes? If not and i follow the id or version number, it can be i edit or translate not the right file.
I will not go to hear or read any kind of reason, it is not really a problem, but in some cases it can be a problem for a user, if he try this module the first time or did not know how can he edit or translate a file.
If we start together at this time and say, let us start with identical version numbers (we can make them inside manually in non english versions). We should not forget, i´m talking only from one module, i dont know the other modules language files look?
think that could be an idea there steve. if a lang define isn't actually defined, then the system uses the english define.
but we have a problem that it would mean the whole english file is loaded which could conflict with the other language defines.
could we have the core automatically prefix lang defines with a country code? say _AM_NOPERM gets prefixed with _ENGB_AM_NOPERM then we could essentially do this, and if _PTBR_AM_NOPERM is not found, then _ENGB_AM_NOPERM is used.
or could we use file_get_contents() to get the english file, and select that define what's missing from the string value that file_get_contents() retrieves.. that way the whole language file isn't gonna cause any issues.
i think there's a few ways we might be able to improve on in this area.
Andy is right - the translation files need to be correct when available. From a core standpoint, we could better handle missing constants in other languages.
Our current method is to load the entire language file, if available. If it isn't we load the english language file. Perhaps we could go a little further and look at the english language file if a particular constant is not defined in the translated language file. It's only an idea at this point - some of the smarter people might find a way to make this work!
$Id: admin.php,v 1.23 2006/11/05
I normally start at the end of a lang-file with adding new variables, starting with mentioning the module version. These variables I copy to other language files in SVN also. This way translators only have to look at the end of a file to see if new variables have been added.
The only downside is that translators can not always keep up with releases.
The new ImpressCMS module currently being developted - imTranslating - will certainly help with people translating modules or core... and hopefully help prevent any issues in the future.
Dear ICMS user, dear icms und supporter
Before i start with my topic, this is not a critic and not any kind of bad words what i have to say. My motivation is only that we all can make some things a little better, for all of us!!! Normally i should wrote my words in the german community, but 1st i think it can be a international problem and 2nd i will not that Rene means my topic target to him, this is not my intention!
Today i work on the wfdownloads module and today, altough i work some years ago with the excellent module, i must change some things in the german laguage files. In the course of my changes, i ask myself, why can we (the icms community) can not bring the language files on one level, specially i mean the versions number. I will give a example what i mean (see the attached files, pictures 1 to 4):
On pic 1 you see and screenshot from the administration panel, and you see the first line is empty. But i should mark "Yes or no" ... :-X
What should i mark? See for the answer pic two, a screeshot with the english language file.
The next example is, see a screenshot in german with the the button labels (here pic 3) and you will see it in english on pic 4.
For the non german user, in the first moment there is not a error, but the english button "Reviews" called in german "Eintrag erstellen" what in english mean, create a new file or a new download.
I´m not a nitpicker dear friends, but i think in this moment not that i know what means this labels, with a click on the button i can see it, i think for the user (in our cases i think at the teacher we support). Sure i can change this in my eyes - error - and give it back to the german and the international community (i my case, i have sometimes the problem, i must change the defines of some entries, that it makes more sense for the appearance). But now comes what i mean we can do a little bit better.
The english language file admin.php has the version number:
$Id: admin.php,v 1.23 2006/11/05
The german language file admin.php has the versuion number:
$Id: admin.php,v 1.19 2006/05/25
Can we not say, we all work on the language file, to correct now all little error or the things we miss and give the files a identical number?
I anythings change, we can give the next version number of that file, if anyone search the curent- or subversion system he can search for the newest files. This i mean guaranteed that all international language files comes to one (at least near) level.
How could we handle that if you see it like me?
Hi JardaR, thanks
i have added your files in our SVN. Thanks a lot your hard work.
Czech language Pack UTF8 for ImpressCMS 1.1 beta from 2008/8/10.
The archive contains complete translation into Czech: Core, phpmailer, install, DHTML form, TinyMCE. May be 100%. :thumbup:
Thank you Weby
Hey again :)
I've just updated SVN with latest slovene language files for 1.1 beta1 release.
Ok, the soluction for this problem is link manager
Perhaps this is the ideal place to demonstrate this new feature. It should work perfectly if it is established the right content, appropriate language blocks and related content.
The ideal for this work will be an integration with the content manager, wf-downloads, custom tags and link manager.
ps: There is a site of tests created by René Sato-which is perhaps possible to demonstrate this work.
Is necessary for some time to consider how best to automate the tasks, but if the team thinks it is worth, we could customize this in the future.
Anyway, I agree with Tom We need to think now about this problem of language in downloads because otherwise I will keep a copy in br.impresscms.org for all translations and versions of modules with a link to review for each comment.
ps2: I do not understand how the site is built internally addons. If you work exclusively with wf-downloads or other connections there is the content.
I was thinking about this also, because with each new release of a module version, a new language pack may become available.
The only idea I could think of was to to edit the module to allow file association. You could publish the main module, then submitting new language files you click a check box or search the module and then submit. When you go to the module or language pack it associates it with the release it's applicable for. (Multiple associations could be chosen).
So if you went to the module download it would be:
When you go to the language pack:
--+ Module it's applicable for
This would also be a great addition for many other purposes also.
I suppose you could think of this like the module would be a category, and the language files would be sub cats (This isn't true but gives you the idea).
Just a thought - more like a question - how easy would it be for a user to download a module and the corresponding language pack? How can we make it stupid simple?
Ok so the proposed structure of categories would be something like:
The module languages would then be uploaded to their own category.
Just wondering on the Addons website we have the modules language section, at the moment there are only about 3 downloads, however with time this will grow and could get out of control.
Should we therefore consider breaking the Modules Language category down into subcategories per language.
Although it wouldn't make so much difference now, it's better to have a firm ongoing solution than spending hours sorting the mess out later.
Here is the current category for Module Languages:
There ... 1.1 translation (I hope ... I used language files from SourceForge SVN from /core/trunk ... hope I used the right files...).