Re: Some question and suggestion about language files

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

Topic


Re: Some question and suggestion about language files

  • 2008/8/17 9:47:19
  • exp

Dear friends

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 $

xxxxxxxxxxxxxxxxxxxxxx

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?

Greetings Andy

Topic


Re: Some question and suggestion about language files

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.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: Some question and suggestion about language files

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!



Re: Some question and suggestion about language files

Quote:


$Id: admin.php,v 1.23 2006/11/05



that id & version number is produced automatically by CVS and increased each time it is committed. you can't reliably count on that version number being the most current. especially with different languages.

everyone is editing different files because each language has a different file. sure we could have all the version numbers the same, but the moment an english person changes his lang file, the version becomes wrong. then if the german translator changes his lang file, his version number is changed also, so then we have to keep syncing file versions.. more work to do.

all changed language field from each release should be in the docs folder inside the language_changelog file. so translators only need to look at that file, and they know what has been added or changed in each release and in what file.

something like:

language/english/admin.php

added: define('THIS_LANG_DEFINE', 'here's an added lang define');
added: define('THIS_LANG_DEFINE2', 'here's an added lang define');

changed:

define('THIS_LANG_DEFINE6000', 'here's an added lang define');

to

define('THIS_LANG_DEFINE600', 'here's an added lang define for 600');

removed:

define('THIS_LANG_DEFINE1234', 'here's an added lang define');


language/english/main.php

and so on.

Live as if you were to die tomorrow, Learn as if you were to live forever

The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together!


Re: Some question and suggestion about language files

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.



Re: Some question and suggestion about language files

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.



Some question and suggestion about language files

  • 2008/8/17 7:14:46
  • exp

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.

xxxxxxxxxxxxxxxxxxxxxxxxxx

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.

xxxxxxxxxxxxxxxxxxxxxxxxxx

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.

xxxxxxxxxxxxxxxxxxxxxxxxxx

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?

Greetings Andy


Attach file:



gif  wfd_1.gif (0.00 KB)


gif  wfd_2.gif (0.00 KB)


gif  wfd_3.gif (0.00 KB)


gif  wfd_4.gif (0.00 KB)





Re: Czech translation for ImpressCMS 1.1 beta

Hi JardaR,

i have added your files in our SVN. Thanks a lot your hard work.



Czech translation for ImpressCMS 1.1 beta

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:


Attach file:


zip czech_utf8_for_impresscms_11_beta.zip Size: 0.00 KB; Hits: 28


Re: Translations

Thank you Weby



Re: Translations

  • 2008/8/12 9:20:53
  • w3by

Hey again :)
I've just updated SVN with latest slovene language files for 1.1 beta1 release.



Re: Addons - Module language files

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.

Giba


Re: Addons - Module language files

  • 2008/5/25 1:34:08
  • Tom

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:

Module
--+ Spanish
--+ German
--+ ETC
--+ ECT

When you go to the language pack:

+ Language
--+ 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).



Re: Addons - Module language files

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?



Re: Addons - Module language files

  • 2008/5/24 16:40:25
  • Tom

Ok so the proposed structure of categories would be something like:

Languages
|
|-+ Modules
|---+Language Name


The module languages would then be uploaded to their own category.





Addons - Module language files

  • 2008/5/24 16:02:37
  • Tom

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:

http://addons.impresscms.org/modules/wfdownloads/viewcat.php?cid=26



Re: Translations

  • 2008/5/18 8:26:15
  • w3by

There ... 1.1 translation (I hope ... I used language files from SourceForge SVN from /core/trunk ... hope I used the right files...).


Attach file:


zip slovenian_v1-1_utf-8.zip Size: 0.00 KB; Hits: 37