Hello, I am evaluating exim4u for some time. I made two installations on Debian squeeze systems. The first I made in February this year and the second yesterday. I liked vexim and now I am going to change to exim4u. Thank you very much for your work, Gordon! There are only a few (minor) problems. One of them is the following on my new installation: In /var/log/mail.info I see the following errors from SpamAssassin: Sep 16 09:32:58 myhost spamd[24356]: spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody Sep 16 09:32:58 myhost spamd[24356]: spamd: checking message <replaced> for spamd:65534 Sep 16 09:33:00 myhost spamd[24356]: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /nonexistent/.spamassassin/bayes.lock.replaced.24356 for /nonexistent/.spamassassin/bayes.lock: No such file or directory The first of these lines also appears in my old installation, but the last of these lines only on the new installation. I guess one may solve this problem by disabling bayes. Can someone indicate me how to do this? Another possibility would be to create a user that will be used for spamassassin checks of exim4u. But I am not so sure if one really wants bayes for such a global user. Where in the exim4u configuration do I find the call of spamc / spamassassin? Kind regards, Udo
Hi Udo, Try the following: Add a user named "spamd": useradd spamd Then, in your spamassassin service script, run spamd us user spamd. Under CentOS, the service script is /etc/init.d/spamassassin which runs spamd as: daemon $NICELEVEL spamd $SPAMDOPTIONS -r $SPAMD_PID The SPAMDOPTIONS variable is defined in /etc/sysconfig/spamassassin as: SPAMDOPTIONS="-d -x -u spamd --max-children=5 --allowed-ips=127.0.0.1" Its been a while since I ran exim4u and spamassassin on a debian system but it should be quite similar. FYI, Gordon On 09/16/2010 03:45 AM, Udo Hortian wrote:
Hello,
I am evaluating exim4u for some time. I made two installations on Debian squeeze systems. The first I made in February this year and the second yesterday. I liked vexim and now I am going to change to exim4u. Thank you very much for your work, Gordon!
There are only a few (minor) problems. One of them is the following on my new installation:
In /var/log/mail.info I see the following errors from SpamAssassin:
Sep 16 09:32:58 myhost spamd[24356]: spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody Sep 16 09:32:58 myhost spamd[24356]: spamd: checking message <replaced> for spamd:65534 Sep 16 09:33:00 myhost spamd[24356]: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /nonexistent/.spamassassin/bayes.lock.replaced.24356 for /nonexistent/.spamassassin/bayes.lock: No such file or directory
The first of these lines also appears in my old installation, but the last of these lines only on the new installation.
I guess one may solve this problem by disabling bayes. Can someone indicate me how to do this?
Another possibility would be to create a user that will be used for spamassassin checks of exim4u. But I am not so sure if one really wants bayes for such a global user. Where in the exim4u configuration do I find the call of spamc / spamassassin?
Kind regards, Udo
_______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hello Gordon, thank you very much for your reply. The solution you proposed resolved the problem. On Debian the options for spamd are in /etc/default/spamassassin But I am wondering if this is really a good solution. Does one want a common bayes database? Would not it be better to do this user-based or do deactivate it? In http://exim4u.org/svn/exim4u_src/trunk/SPAMASSASSIN you write under point 6) about user specific spamassassin settings. But it seems that this does not really apply to exim4u, is not it? I think usually one would run exim4u with a single (or a few) user account, is not it? I mean not every virtual mail account will have an own system account. Kind regards, Udo
Hi Udo, While I am not 100% sure, I think that SpamAssassin's user based bayes system was not originally designed for virtual domains. That is, it was designed assuming that each machine would host only one domain and each mail user on that machine would have their own PAM account, directory structure and mail file. Therefore, it probably does not make alot of sense to try to do user based bayes reporting with most modern mail systems since most modern mail systems, such as Exim4U, use virtual domains. Any difference between a user based bayes system versus a common bayes system would depend on whether or not you were reporting spam to SpamAssassin with sa-learn. However, due to SpamAssassin's autolearn feature, I believe that there are benefits from using the bayes system with a common bayes database even if you are not reporting spam with sa-learn. Exim4U's recommended SpamAssassin configuration utilizes many other SpamAssassin checks such as the Open Protect Rules Channel and the checksum tests with Razor, DCC and Pyzor all of which help SpamAssassin accurately determine spam from ham. Therefore, the bayes autolearn system subsequently benefits from the overall SpamAssassin results in associating which tokens, character sequences and words are contained in spam mail versus ham mail as dictated by the many other SpamAssassin checks. I generally setup my installations to use a common bayes implementation with autolearn enabled. However, I am not a SpamAssassin expert so I would recommend that you pursue these questions further on the SpamAssassin mailing lists here: http://wiki.apache.org/spamassassin/MailingLists I hope that this helps. Gordon On 09/16/2010 01:58 PM, Udo Hortian wrote:
Hello Gordon,
thank you very much for your reply. The solution you proposed resolved the problem. On Debian the options for spamd are in /etc/default/spamassassin
But I am wondering if this is really a good solution. Does one want a common bayes database? Would not it be better to do this user-based or do deactivate it?
In http://exim4u.org/svn/exim4u_src/trunk/SPAMASSASSIN you write under point 6) about user specific spamassassin settings. But it seems that this does not really apply to exim4u, is not it? I think usually one would run exim4u with a single (or a few) user account, is not it? I mean not every virtual mail account will have an own system account.
Kind regards, Udo
_______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hello, I've just installed Exim4u on Ubuntu 10.04 with cyrillic locale (ru_RU) There are few problems I can't resolve myself: 1) Are exim4u scripts utf-8 compatible? When I add a new user in siteadmin interface and assign a name for this user in Russian I get unreadable symbols in phpMyadmin, though UTF-8 is set up by default in MySQL. Looking at db structure I noticed that for some reason all tables in exim4u database were created in *latin1_swedish_ci* encoding. More strange is that gtreeting message (which is sent to user after siteadmin has created an account) is neveretheless in UTF-8! All my users are windows-and-Mac and their clients prefer to get email in cp-1251. I tried to write by hand that corresponding text in /config/variables.php in necessary encoding (1251) but now I get unreadable symbols instead of name both in phpMyadmin AND in body of greeting message, but in header there is a mix of English and Russian: "Welcome, Вася!... Where can I change it so all parts of message were in Russian (1251 or in UTF-8 at least)? 2) Exim4u tries to make maildir "/Maildir" after everything else I set, but dovecot by default makes directory INBOX, thus message when recieved can not be read by client (it looks in INBOX dir). That's Ok, I changed it by hand in several scripts in exim4u directory. Is this an error on my side or it was by design? 3) I'm going to translate Exim4u interface to Russian and here I have a couple of questions: - what is "Add Fail"? what is "Fail" in this meaning? - what is "Catchall"? is that sort of "forward all non-existent messages to somewhere"? Thank you in advance, Alexandr
On 10/17/2010 02:38 PM, azlk wrote:
1) Are exim4u scripts utf-8 compatible? When I add a new user in siteadmin interface and assign a name for this user in Russian I get unreadable symbols in phpMyadmin, though UTF-8 is set up by default in MySQL. Looking at db structure I noticed that for some reason all tables in exim4u database were created in *latin1_swedish_ci* encoding. More strange is that gtreeting message (which is sent to user after siteadmin has created an account) is neveretheless in UTF-8! All my users are windows-and-Mac and their clients prefer to get email in cp-1251. I tried to write by hand that corresponding text in /config/variables.php in necessary encoding (1251) but now I get unreadable symbols instead of name both in phpMyadmin AND in body of greeting message, but in header there is a mix of English and Russian: "Welcome, Вася!... Where can I change it so all parts of message were in Russian (1251 or in UTF-8 at least)?
Hi Alexandr, I regret having to report that I don't have any experience with the language files and so I don't know the best way to recommend that you proceed. The language files were written back when Vexim was initially designed and that original work has not been modified by the Exim4U project. The language files are located in the "locale" directory and I believe that the language to be used is specified in the config/i18n.php file. Sorry that I am no more help here. You may possibly get better answers by a Vexim user/developer here or on the Vexim list here: http://silverwraith.com/mailman/listinfo/vexim
2) Exim4u tries to make maildir "/Maildir" after everything else I set, but dovecot by default makes directory INBOX, thus message when recieved can not be read by client (it looks in INBOX dir). That's Ok, I changed it by hand in several scripts in exim4u directory. Is this an error on my side or it was by design?
Mail is typically stored as follows: /home/exim4u/mail/<domail.tld>/<username>/Maildir I believe that your dovecot configuration may be incorrect. Please review the sample dovecot configuration files in the Exim4U distributions etc directory: etc/dovecot-sql.conf etc/dovecot.conf etc/dovecot/dovecot.111.222.333.444.conf etc/dovecot/dovecot.127.0.0.1.conf I think that you may have configured dovecot for mbox storage instead of maildir storage.
3) I'm going to translate Exim4u interface to Russian and here I have a couple of questions: - what is "Add Fail"? what is "Fail" in this meaning? - what is "Catchall"? is that sort of "forward all non-existent messages to somewhere"?
That is great news! Let me know when your Russian translation is complete. I would like to incorporate any language improvements/bug fixes that you come up with. "Add Fail" is a domain menu option that was in the original Vexim code on which Exim4U is based. All that it does is cause individual email addresses to fail with a 550 error code but without any other explanation. Otherwise, without the "Fail" entry, the mail would fail with a 550 error code as well as a text explanation such as: "No such person at this address". I don't have any idea why the Vexim project included this option but I did not remove it for Exim4U. I realize that this is a rather flaky explanation.... Gordon
Hi Alexandr, I just noticed that the link to the Vexim mailing list in my previous email is broken:
I have sent an email to Avleen Vig (Vexim Project Leader) about this and requested that he fix the link. So, hopefully, it will be fixed soon. FYI, Gordon On 10/17/2010 09:30 PM, Gordon Dickens wrote:
On 10/17/2010 02:38 PM, azlk wrote:
1) Are exim4u scripts utf-8 compatible? When I add a new user in siteadmin interface and assign a name for this user in Russian I get unreadable symbols in phpMyadmin, though UTF-8 is set up by default in MySQL. Looking at db structure I noticed that for some reason all tables in exim4u database were created in *latin1_swedish_ci* encoding. More strange is that gtreeting message (which is sent to user after siteadmin has created an account) is neveretheless in UTF-8! All my users are windows-and-Mac and their clients prefer to get email in cp-1251. I tried to write by hand that corresponding text in /config/variables.php in necessary encoding (1251) but now I get unreadable symbols instead of name both in phpMyadmin AND in body of greeting message, but in header there is a mix of English and Russian: "Welcome, Вася!... Where can I change it so all parts of message were in Russian (1251 or in UTF-8 at least)?
Hi Alexandr,
I regret having to report that I don't have any experience with the language files and so I don't know the best way to recommend that you proceed. The language files were written back when Vexim was initially designed and that original work has not been modified by the Exim4U project. The language files are located in the "locale" directory and I believe that the language to be used is specified in the config/i18n.php file. Sorry that I am no more help here. You may possibly get better answers by a Vexim user/developer here or on the Vexim list here:
http://silverwraith.com/mailman/listinfo/vexim
2) Exim4u tries to make maildir "/Maildir" after everything else I set, but dovecot by default makes directory INBOX, thus message when recieved can not be read by client (it looks in INBOX dir). That's Ok, I changed it by hand in several scripts in exim4u directory. Is this an error on my side or it was by design?
Mail is typically stored as follows:
/home/exim4u/mail/<domail.tld>/<username>/Maildir
I believe that your dovecot configuration may be incorrect. Please review the sample dovecot configuration files in the Exim4U distributions etc directory:
etc/dovecot-sql.conf etc/dovecot.conf etc/dovecot/dovecot.111.222.333.444.conf etc/dovecot/dovecot.127.0.0.1.conf
I think that you may have configured dovecot for mbox storage instead of maildir storage.
3) I'm going to translate Exim4u interface to Russian and here I have a couple of questions: - what is "Add Fail"? what is "Fail" in this meaning? - what is "Catchall"? is that sort of "forward all non-existent messages to somewhere"?
That is great news! Let me know when your Russian translation is complete. I would like to incorporate any language improvements/bug fixes that you come up with.
"Add Fail" is a domain menu option that was in the original Vexim code on which Exim4U is based. All that it does is cause individual email addresses to fail with a 550 error code but without any other explanation. Otherwise, without the "Fail" entry, the mail would fail with a 550 error code as well as a text explanation such as: "No such person at this address". I don't have any idea why the Vexim project included this option but I did not remove it for Exim4U. I realize that this is a rather flaky explanation....
Gordon
_______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
18.10.2010 05:30, Gordon Dickens пишет:
On 10/17/2010 02:38 PM, azlk wrote:
1) Are exim4u scripts utf-8 compatible? When I add a new user in siteadmin interface and assign a name for this user in Russian I get unreadable symbols in phpMyadmin, though UTF-8 is set up by default in MySQL. Looking at db structure I noticed that for some reason all tables in exim4u database were created in *latin1_swedish_ci* encoding. More strange is that gtreeting message (which is sent to user after siteadmin has created an account) is neveretheless in UTF-8! All my users are windows-and-Mac and their clients prefer to get email in cp-1251. I tried to write by hand that corresponding text in /config/variables.php in necessary encoding (1251) but now I get unreadable symbols instead of name both in phpMyadmin AND in body of greeting message, but in header there is a mix of English and Russian: "Welcome, Вася!... Where can I change it so all parts of message were in Russian (1251 or in UTF-8 at least)?
Hi Alexandr,
I regret having to report that I don't have any experience with the language files and so I don't know the best way to recommend that you proceed. The language files were written back when Vexim was initially designed and that original work has not been modified by the Exim4U project. The language files are located in the "locale" directory and I believe that the language to be used is specified in the config/i18n.php file. Sorry that I am no more help here. You may possibly get better answers by a Vexim user/developer here or on the Vexim list here:
http://silverwraith.com/mailman/listinfo/vexim
2) Exim4u tries to make maildir "/Maildir" after everything else I set, but dovecot by default makes directory INBOX, thus message when recieved can not be read by client (it looks in INBOX dir). That's Ok, I changed it by hand in several scripts in exim4u directory. Is this an error on my side or it was by design?
Mail is typically stored as follows:
/home/exim4u/mail/<domail.tld>/<username>/Maildir
I believe that your dovecot configuration may be incorrect. Please review the sample dovecot configuration files in the Exim4U distributions etc directory:
etc/dovecot-sql.conf etc/dovecot.conf etc/dovecot/dovecot.111.222.333.444.conf etc/dovecot/dovecot.127.0.0.1.conf
I think that you may have configured dovecot for mbox storage instead of maildir storage.
3) I'm going to translate Exim4u interface to Russian and here I have a couple of questions: - what is "Add Fail"? what is "Fail" in this meaning? - what is "Catchall"? is that sort of "forward all non-existent messages to somewhere"?
That is great news! Let me know when your Russian translation is complete. I would like to incorporate any language improvements/bug fixes that you come up with.
"Add Fail" is a domain menu option that was in the original Vexim code on which Exim4U is based. All that it does is cause individual email addresses to fail with a 550 error code but without any other explanation. Otherwise, without the "Fail" entry, the mail would fail with a 550 error code as well as a text explanation such as: "No such person at this address". I don't have any idea why the Vexim project included this option but I did not remove it for Exim4U. I realize that this is a rather flaky explanation....
Gordon
_______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hello, Gordon! I've finished my translation tonight and going to send it to you. Unfortunately, there is not only .po-file, but a lot of fixes in PHP code, so I have to send ALL files... I archived them and the file is about 60Kb so I attach it here. Look inside, please, I placed README_Gordon!!! file there with all details so you could know what was done. Hope I could be of use for you great project and other people! And Thank you! :-D Alexandr
On 10/25/2010 05:04 AM, azlk wrote:
Hello, Gordon!
I've finished my translation tonight and going to send it to you. Unfortunately, there is not only .po-file, but a lot of fixes in PHP code, so I have to send ALL files... I archived them and the file is about 60Kb so I attach it here. Look inside, please, I placed README_Gordon!!! file there with all details so you could know what was done. Hope I could be of use for you great project and other people! And Thank you! :-D
Alexandr
Hi Alexandr, Thanks for doing the Russian translation and working on all the language related code. I want to study the results of your work for potentially including it in an upcoming version of Exim4U. Also, I will reply directly off-list to you regarding your README_Gordon file. Thanks again! Gordon
Hi Alexandr, I decided to reply to the list regarding the README_Gordon file in your tar ball so that other folks could read our exchange and potentially participate.
1) First of all, there were a lot of mistakes in PHP concerning gettext - many messages were not translated at all. I've spent a lot of time looking for possible resolutions just because I don't know PHP at all... I think I've got something really working now: every message is translated! But if you would take a pure .po-file it will not work because of those multiple mistakes in PHP-code. This is why I have to send you all the code back. Probably a better idea is to re-check everything, though I didn't find any changes in 1.2.4 from 1.2.3. While translating I found many strings were absent in original .po, but unfortunately I didn't guess from the beginning to include file names with respective line numbers into ru.po. So some strings are simply there and I can't say now where they are from, excuse me...
You really did make quite a few changes! I have done a brief review of your changes and most or your edits look like syntax issues that were repeated (and corrected) over and over. Do you believe that these changes would work for the other language files that are included in Exim4U's locale directory from the old Vexim code (de_DE, en_EN, es_ES, hu_HU and ro_RO)? Obviously, I can test the English version. Unfortunately, I am not multilingual so I would like to find other folks to test these other languages. Hopefully, we may get some volunteers..... I would like for you to run your revised code for a few weeks and let us know how it goes. After that, if you are happy with it then I would like to post your tar ball as a "Beta Test Russian version" on the Exim4U downloads page at http://exim4u.org/download/. Furthermore, at that time, I will begin testing in English and hopefully some other folks might volunteer to test the other languages. Once we gain confidence that all is well then we can look to integrate your changes into the trunk.
2) There are string about Anti-Virus but I can't find anything like in web-interface?...
The original Vexim code provided each individual domain and user with the option of enabling or disabling the ClamAV antivirus checks. This was possible since Vexim ran ClamAV and SpamAssassin in the Routers section of the exim configuration file after the mail had been accepted. However, it is more efficient and standards compliant to run ClamAV and SpamAssassin during the data ACL prior to accepting mail which is how we do it with Exim4U. Therefore, rejections occur during the SMTP session instead of after the mail has been accepted. In any event, as a result of all this, the capability for individual domains and users to enable/disable the ClamAV checks are not possible and the Anti-Virus verbage in the PHP code is no longer relevant and can therefore be ignored.
3) Next, more important question: I see that all passwords are kept in CLEAR in database... Is that good, really???... If I only knew PHP a bit I could fix that myself, but no way...
No, that is far less than perfect to store the passwords that way. We probably should add that to our TODO list.
5) I've changed CSS a bit so that text was located more uniformly on the screen, tested it in Opera, Firefox and Chrome. IE never worried me in this life, sorry :-)
That sounds fine. This is something else for us to look for when we test your changes. Alexandr, in summary, thanks again for doing the Russian translation, for addressing the other issues that you found in the language files and for forwarding your revised code back to us for further review. Please let me know how things are going after a few weeks have passed. Gordon
Hello, Gordon, You mentioned some things which were obvious but I had missed them in my letter. You are right, not all of this code may work properly for other languages. This is because of how sentences are composed in the code. For example, in adduser page there one can see a phrase at the bottom: "Blocked Headers To Be Deleted" This phrase in .po file is composed from 3 parts (why?!): - "Blocked" - "Headres To Be" - "Deleted" So when I translated these separate parts into Russian I got very funny message which sounds in Russian like "Blocked-headers-deleted-to-be". In such form this is abracadabra, so I had to translate each part intentionally wrong to get meaningfull sentence in the end. Thus, "Headers To Be" became "Deleted", "Deleted" became "Headers" and "Blocked" stayed "Blocked". There are other examples which I didn't mention. I realize that for anyone who don't know other languages it's quite a complex task to compose string in such manner that they could be properly translated to other languages. But we could rearrange strings to make them more compatible, couldn't we? For example the string from above example don't repeat anywhere else, so I suppose it could be just one sentence, then this whole thing can be easily translated to any language without confusing. Also, I found a few words which are there in code but due to my poor knowledge I didn't understand yet how to make them gettext-compatible. Some of them are in config/headers(xxx).php files and some are in php files in main direcory. Probably you are right, I have to try to rearrange strings and then test all thing for some time. Hope this will result in more i18n-compatible .po-file. Anti-Virus. If it is not used, maybe we could remove these strings to not confuse future translators? Sincerely, Alexandr 26.10.2010 06:45, Gordon Dickens пишет:
Hi Alexandr,
I decided to reply to the list regarding the README_Gordon file in your tar ball so that other folks could read our exchange and potentially participate.
1) First of all, there were a lot of mistakes in PHP concerning gettext - many messages were not translated at all. I've spent a lot of time looking for possible resolutions just because I don't know PHP at all... I think I've got something really working now: every message is translated! But if you would take a pure .po-file it will not work because of those multiple mistakes in PHP-code. This is why I have to send you all the code back. Probably a better idea is to re-check everything, though I didn't find any changes in 1.2.4 from 1.2.3. While translating I found many strings were absent in original .po, but unfortunately I didn't guess from the beginning to include file names with respective line numbers into ru.po. So some strings are simply there and I can't say now where they are from, excuse me...
You really did make quite a few changes! I have done a brief review of your changes and most or your edits look like syntax issues that were repeated (and corrected) over and over.
Do you believe that these changes would work for the other language files that are included in Exim4U's locale directory from the old Vexim code (de_DE, en_EN, es_ES, hu_HU and ro_RO)? Obviously, I can test the English version. Unfortunately, I am not multilingual so I would like to find other folks to test these other languages. Hopefully, we may get some volunteers.....
I would like for you to run your revised code for a few weeks and let us know how it goes. After that, if you are happy with it then I would like to post your tar ball as a "Beta Test Russian version" on the Exim4U downloads page at http://exim4u.org/download/. Furthermore, at that time, I will begin testing in English and hopefully some other folks might volunteer to test the other languages. Once we gain confidence that all is well then we can look to integrate your changes into the trunk.
2) There are string about Anti-Virus but I can't find anything like in web-interface?...
The original Vexim code provided each individual domain and user with the option of enabling or disabling the ClamAV antivirus checks. This was possible since Vexim ran ClamAV and SpamAssassin in the Routers section of the exim configuration file after the mail had been accepted. However, it is more efficient and standards compliant to run ClamAV and SpamAssassin during the data ACL prior to accepting mail which is how we do it with Exim4U. Therefore, rejections occur during the SMTP session instead of after the mail has been accepted. In any event, as a result of all this, the capability for individual domains and users to enable/disable the ClamAV checks are not possible and the Anti-Virus verbage in the PHP code is no longer relevant and can therefore be ignored.
3) Next, more important question: I see that all passwords are kept in CLEAR in database... Is that good, really???... If I only knew PHP a bit I could fix that myself, but no way...
No, that is far less than perfect to store the passwords that way. We probably should add that to our TODO list.
5) I've changed CSS a bit so that text was located more uniformly on the screen, tested it in Opera, Firefox and Chrome. IE never worried me in this life, sorry :-)
That sounds fine. This is something else for us to look for when we test your changes.
Alexandr, in summary, thanks again for doing the Russian translation, for addressing the other issues that you found in the language files and for forwarding your revised code back to us for further review. Please let me know how things are going after a few weeks have passed.
Gordon
_______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hi Alexandr, Thanks for the update. Let me know if/when you have the code ready to test and I will test and evaluate it at that time. Personally, I think that it would be fine to rearrange strings to make them more compatible for the various languages. And yes, you are correct to go ahead and remove the strings related to the Anti-Virus implementation. Thanks again for your efforts! Gordon On 10/26/2010 12:13 PM, azlk wrote:
Hello, Gordon,
You mentioned some things which were obvious but I had missed them in my letter. You are right, not all of this code may work properly for other languages. This is because of how sentences are composed in the code. For example, in adduser page there one can see a phrase at the bottom: "Blocked Headers To Be Deleted" This phrase in .po file is composed from 3 parts (why?!): - "Blocked" - "Headres To Be" - "Deleted" So when I translated these separate parts into Russian I got very funny message which sounds in Russian like "Blocked-headers-deleted-to-be". In such form this is abracadabra, so I had to translate each part intentionally wrong to get meaningfull sentence in the end. Thus, "Headers To Be" became "Deleted", "Deleted" became "Headers" and "Blocked" stayed "Blocked". There are other examples which I didn't mention. I realize that for anyone who don't know other languages it's quite a complex task to compose string in such manner that they could be properly translated to other languages. But we could rearrange strings to make them more compatible, couldn't we? For example the string from above example don't repeat anywhere else, so I suppose it could be just one sentence, then this whole thing can be easily translated to any language without confusing.
Also, I found a few words which are there in code but due to my poor knowledge I didn't understand yet how to make them gettext-compatible. Some of them are in config/headers(xxx).php files and some are in php files in main direcory. Probably you are right, I have to try to rearrange strings and then test all thing for some time. Hope this will result in more i18n-compatible .po-file.
Anti-Virus. If it is not used, maybe we could remove these strings to not confuse future translators?
Sincerely, Alexandr
participants (3)
-
azlk -
Gordon Dickens -
Udo Hortian