Project

General

Profile

Bug #627

Some problems about Chamilo 1.8.x translation

Added by Ivan Tcholakov about 12 years ago. Updated about 11 years ago.

Status:
Feature implemented
Priority:
Normal
Assignee:
-
Target version:
Start date:
22/02/2010
Due date:
% Done:

100%

Estimated time:
Complexity:
Normal

Description

1.

File: chamilo/application/lib/cda/cda_manager/component/translation_importer/importer/chamilo1_translation_importer.class.php
The method scan_for_language_translations() is not good. I did not test it, code speaks enough.

2.

When translations are exported, for Chamilo 1.8.x some folders should be renamed in the old, legacy way:

'basque' should be renamed as 'euskera'
'turkish' should be renamed as 'turkce'


Files

esperanto.zip (76.7 KB) esperanto.zip Ivan Tcholakov, 22/02/2010 20:18
finnish.zip (52.7 KB) finnish.zip Ivan Tcholakov, 22/02/2010 20:18
georgian.zip (453 Bytes) georgian.zip Ivan Tcholakov, 22/02/2010 20:18
greek.zip (57.7 KB) greek.zip Ivan Tcholakov, 22/02/2010 20:18
arabic.zip (106 KB) arabic.zip Ivan Tcholakov, 22/02/2010 20:18
bosnian.zip (1020 Bytes) bosnian.zip Ivan Tcholakov, 22/02/2010 20:18
bulgarian.zip (153 KB) bulgarian.zip Ivan Tcholakov, 22/02/2010 20:18
hebrew.zip (438 Bytes) hebrew.zip Ivan Tcholakov, 22/02/2010 20:18
croatian.zip (100 KB) croatian.zip Ivan Tcholakov, 22/02/2010 20:18
czech.zip (60.3 KB) czech.zip Ivan Tcholakov, 22/02/2010 20:18
latvian.zip (49.1 KB) latvian.zip Ivan Tcholakov, 22/02/2010 20:21
lithuanian.zip (89 KB) lithuanian.zip Ivan Tcholakov, 22/02/2010 20:21
macedonian.zip (106 KB) macedonian.zip Ivan Tcholakov, 22/02/2010 20:21
malay.zip (25.4 KB) malay.zip Ivan Tcholakov, 22/02/2010 20:21
hebrew.zip (438 Bytes) hebrew.zip Ivan Tcholakov, 22/02/2010 20:21
hungarian.zip (115 KB) hungarian.zip Ivan Tcholakov, 22/02/2010 20:21
indonesian.zip (71.1 KB) indonesian.zip Ivan Tcholakov, 22/02/2010 20:21
norwegian.zip (24.9 KB) norwegian.zip Ivan Tcholakov, 22/02/2010 20:21
japanese.zip (17.1 KB) japanese.zip Ivan Tcholakov, 22/02/2010 20:21
korean.zip (53 KB) korean.zip Ivan Tcholakov, 22/02/2010 20:21
simpl_chinese.zip (76.9 KB) simpl_chinese.zip Ivan Tcholakov, 22/02/2010 20:26
slovak.zip (109 KB) slovak.zip Ivan Tcholakov, 22/02/2010 20:26
slovenian.zip (136 KB) slovenian.zip Ivan Tcholakov, 22/02/2010 20:26
thai.zip (80.5 KB) thai.zip Ivan Tcholakov, 22/02/2010 20:26
persian.zip (68.1 KB) persian.zip Ivan Tcholakov, 22/02/2010 20:26
polish.zip (80.2 KB) polish.zip Ivan Tcholakov, 22/02/2010 20:26
romanian.zip (110 KB) romanian.zip Ivan Tcholakov, 22/02/2010 20:26
trad_chinese.zip (90.6 KB) trad_chinese.zip Ivan Tcholakov, 22/02/2010 20:26
russian.zip (115 KB) russian.zip Ivan Tcholakov, 22/02/2010 20:26
serbian.zip (85.5 KB) serbian.zip Ivan Tcholakov, 22/02/2010 20:26
turkish.zip (99.6 KB) turkish.zip Ivan Tcholakov, 22/02/2010 20:27
ukrainian.zip (64.6 KB) ukrainian.zip Ivan Tcholakov, 22/02/2010 20:27
vietnamese.zip (26.7 KB) vietnamese.zip Ivan Tcholakov, 22/02/2010 20:27
yoruba.zip (876 Bytes) yoruba.zip Ivan Tcholakov, 22/02/2010 20:27
english.zip (123 KB) english.zip Ivan Tcholakov, 22/02/2010 20:31
french.zip (140 KB) french.zip Ivan Tcholakov, 22/02/2010 20:31
friulian.zip (245 Bytes) friulian.zip Ivan Tcholakov, 22/02/2010 20:31
galician.zip (117 KB) galician.zip Ivan Tcholakov, 22/02/2010 20:31
asturian.zip (143 KB) asturian.zip Ivan Tcholakov, 22/02/2010 20:31
brazilian.zip (132 KB) brazilian.zip Ivan Tcholakov, 22/02/2010 20:31
catalan.zip (122 KB) catalan.zip Ivan Tcholakov, 22/02/2010 20:31
german.zip (119 KB) german.zip Ivan Tcholakov, 22/02/2010 20:31
danish.zip (88.7 KB) danish.zip Ivan Tcholakov, 22/02/2010 20:31
dutch.zip (118 KB) dutch.zip Ivan Tcholakov, 22/02/2010 20:31
spanish.zip (142 KB) spanish.zip Ivan Tcholakov, 22/02/2010 20:34
swedish.zip (90.5 KB) swedish.zip Ivan Tcholakov, 22/02/2010 20:34
german.zip (119 KB) german.zip Ivan Tcholakov, 22/02/2010 20:34
italian.zip (131 KB) italian.zip Ivan Tcholakov, 22/02/2010 20:34
occitan.zip (9.92 KB) occitan.zip Ivan Tcholakov, 22/02/2010 20:34
portuguese.zip (137 KB) portuguese.zip Ivan Tcholakov, 22/02/2010 20:34
quechua_cusco.zip (134 KB) quechua_cusco.zip Ivan Tcholakov, 22/02/2010 20:34
unzipping_with_wrong_filenames.png (136 KB) unzipping_with_wrong_filenames.png Ivan Tcholakov, 24/02/2010 17:51
unzipping_with_correct_filenames.png (128 KB) unzipping_with_correct_filenames.png Ivan Tcholakov, 24/02/2010 17:51
all_the_imported_translations_are_outdated_why.png (231 KB) all_the_imported_translations_are_outdated_why.png Ivan Tcholakov, 24/02/2010 18:15
simpl_chinese.png (39.8 KB) simpl_chinese.png Ivan Tcholakov, 27/02/2010 07:18
greek.png (95.4 KB) greek.png Ivan Tcholakov, 27/02/2010 07:18

Related issues

Related to Chamilo LMS - Feature #272: UTF-8 native supportFeature implemented03/12/2009

Actions

History

#1

Updated by Ivan Tcholakov about 12 years ago

#2

Updated by Ivan Tcholakov about 12 years ago

566:d2c80b648a4b Bug #627 - CDA: Proposing code about problem 2, Renaming is needed for Chamilo 1.8.x: 'basque' --> 'euskera'; 'turkish' --> 'turkce'.
http://code.google.com/p/chamilo/source/detail?r=d2c80b648a4b1f9c22391b356e1a1cb66fb12b8b&repo=chamilo

#3

Updated by Ivan Tcholakov about 12 years ago

I took the task #620 which goal has been modified. I will make the attempts for importing the non-latin languages, i.e. those that have nothing to do with ISO-8859-1(5). I need the patches I have sent to be applied on CDA, I hope, this has been done. First, I am going to make a test by importing Bulgarian language only.

#4

Updated by Ivan Tcholakov about 12 years ago

Apparently the code of the CDA tool has not been updated. Ok, for now I am storing here the files I intend to import later.

#5

Updated by Ivan Tcholakov about 12 years ago

Language files for import (2)

#6

Updated by Ivan Tcholakov about 12 years ago

Language files for import (3)

#7

Updated by Ivan Tcholakov about 12 years ago

Language files for import (4)

#8

Updated by Ivan Tcholakov about 12 years ago

Language files not to be imported by me, they are just 'for the record' (1)

#9

Updated by Ivan Tcholakov about 12 years ago

Language files not to be imported by me, they are just 'for the record' (2)

#10

Updated by Ivan Tcholakov about 12 years ago

Ivan Tcholakov wrote:

Language files not to be imported by me, they are just 'for the record' (2)

#11

Updated by Ivan Tcholakov about 12 years ago

It seems to me, before re-importing a language, it should be deleted first. I am going to delete Bulgarian translations for Chamilo 1.8.x branch and to import them again.

#12

Updated by Ivan Tcholakov about 12 years ago

Ivan Tcholakov wrote:

It seems to me, before re-importing a language, it should be deleted first. I am going to delete Bulgarian translations for Chamilo 1.8.x branch and to import them again.

... tomorrow, let Sven make a backup first.

#13

Updated by Ivan Tcholakov about 12 years ago

Sven, I need help here. I deleted the Bulgarian language, then I recreated it. Now the Bulgarian translations are empty. Then, I tried to import the Bulgarian translations using the file bulgarian.zip. The serves processes the file, but eventually translations are not imported.

Could you provide me assistance about two issues:
1. whether the code on the server is updated to its last changeset;
2. whether there is something wrong in the internal structure in the file bulgarian.zip.

#14

Updated by Sven Vanpoucke about 12 years ago

Ivan Tcholakov wrote:

Sven, I need help here. I deleted the Bulgarian language, then I recreated it. Now the Bulgarian translations are empty. Then, I tried to import the Bulgarian translations using the file bulgarian.zip. The serves processes the file, but eventually translations are not imported.

Could you provide me assistance about two issues:
1. whether the code on the server is updated to its last changeset;
2. whether there is something wrong in the internal structure in the file bulgarian.zip.

The code was not yet updated, i will do it now and i hope the system will still work.
EDIT: after update import does not yet seem to work.
I unpacked it, zipped it again and then i was able to import the language. Don't know if your compression technic is the correct one.

#15

Updated by Ivan Tcholakov about 12 years ago

I compessed the files using the IZArc utility http://www.izarc.org/ under Windows, which I use for years. If you unzip manually the files under Ubuntu there is no problem.

The problem I discovered, is that in this specific case (PCLZIP_OPT_PATH) the PclZip library does not treat the back slash as directory separator. On the first picture you may see the wrong result. After repacking the archive under Ubuntu, unpacking by PclZip is correct, see the second picture.

Although the problem can be avoided by repacking, I think, this is a bug in the PclZip library, even in its last version 2.8.2. I should notify the author.

#16

Updated by Ivan Tcholakov about 12 years ago

Within the previous message I've forgotten to attach the pictures, here they are...

#17

Updated by Ivan Tcholakov about 12 years ago

Now, I imported the Bulgarian files, they are good. Translations are not truncated, they contain UTF-8 encoded strings.

But there is yet another problem (number 4). All the imported translations are declared as "outdated". Is it a good choice?

I made some changes to "verified" using the UI (slow), of course this is not the way to deal with the problem.

Could someone fix this? A picture is attached.

#18

Updated by Marko Kastelic about 12 years ago

ivan, i can't see any english 'translation'. Maybe this is a reason, that all (mine, slovenian) the files are outdated ..

#19

Updated by Marko Kastelic about 12 years ago

i'm taking back previous. Just forget it. Filters were obviously fixed in last few days ....

#20

Updated by Ivan Tcholakov about 12 years ago

10559:97e07ad18d21 Bug #627 - Chamilo 1.8.7, PclZip 2.8.2 library: Applying a patch for compatibility of PclZip with some Windows-implemented archivers. Stored in an archive filenames with backslashes (Windows style) are interpreted correctly now.
http://code.google.com/p/chamilo/source/detail?r=97e07ad18d215dad19f9d35303eb83671685f6f6&repo=classic

589:9cf78617a719 Bug #627 - Chamilo 2.0, PclZip 2.6 library: Applying a patch for compatibility of PclZip with some Windows-implemented archivers. Applying other known patches.
http://code.google.com/p/chamilo/source/detail?r=9cf78617a719a710730c8fd95e4f308bce8be6c8&repo=chamilo

I think, after updating code on CDA server, problem 3 would be solved. The created with windows-based utility zip-files I uploaded here should be read by PclZip library without problems.

#21

Updated by Sven Vanpoucke about 12 years ago

Updated to latest code

#22

Updated by Ivan Tcholakov about 12 years ago

I played with the Bulgarian language. With the patched PclZip the file "bulgarian.zip" works as it was uploaded here. There is no need for repacking. I am sure that the zip-files for the other languages would work too, but I don't want to play with them right now.

I upgraded the library PclZip to it newest version 2.8.2 with two patches. It intend to test it with importing languages too. I am sure, it will work too.

The essential problem left is number 4: How while importing language translations not to be declared as "outdated". This is the next patch I will try to make in about 24 hours.

#23

Updated by Ivan Tcholakov about 12 years ago

599:9264240c5915 Bug #627 - CDA: Trying to solve problem 4. I want all the imported translations to be marked as "verified", not as "outdated".
http://code.google.com/p/chamilo/source/detail?r=9264240c5915f3e4686676d544e24a77821cc61f&repo=chamilo

I need updating code on the CDA-server again...

#24

Updated by Ivan Tcholakov about 12 years ago

It is Friday, please, update the CDA-server. I expect problem 4 to be solved, then I will be able to re-import some languages.

#25

Updated by Sven Vanpoucke about 12 years ago

Ok, code is updated.

#26

Updated by Ivan Tcholakov about 12 years ago

I think, the problem 4 has been solved. The Bulgarian language is marked as outdated, but this is due to the previous attempts for importing files.
I am going to prepare and import 1.8.x corrective language files for solving the following problems:
1. the truncated strings to 255 cahrates;
2. htmlentities inside translations for some languages.

#27

Updated by Yannick Warnier about 12 years ago

Did you get to fix the \\" problem as well? I don't mind sharing your packaging scripts. I need to re-import the es-en-fr variables of >255 chars (only these ones).

#28

Updated by Ivan Tcholakov about 12 years ago

Yannick Warnier wrote:

Did you get to fix the \" problem as well? I don't mind sharing your packaging scripts. I need to re-import the es-en-fr variables of >255 chars (only these ones).

I've just re-imported >250 chars (counted on html-enity-type strings) for all the languages. The script corrects the \" and \\ problems. Now I am going to re-import (slowly) all the languages that are polluted with html-entities.

#29

Updated by Yannick Warnier about 12 years ago

Great! Thank you very much, that is great news. I'll send an official news about 1.8.7 and the proposed schedule in a bit here on redmine.

#30

Updated by Ivan Tcholakov about 12 years ago

10574:26cb2b597947 Tasks #620 and #627 - The second attempt to use exported Chamilo 1.8.x translations from CDA, http://translate.chamilo.org
http://code.google.com/p/chamilo/source/detail?r=26cb2b597947c809fda7ce190b72ca5b6bd4c426&repo=classic

#31

Updated by Ivan Tcholakov about 12 years ago

10575:57ed73ae60f4 Tasks #620 and #627 - Fixing manually syntax errors. Still I have a problem (overescaping) with the exported data.
http://code.google.com/p/chamilo/source/detail?r=57ed73ae60f4275a302d7d4ee595de9353a526b0&repo=classic

#32

Updated by Ivan Tcholakov about 12 years ago

10582:d825c902a982 Tasks #620 and #627 - The third attempt to use exported Chamilo 1.8.x translations from CDA, http://translate.chamilo.org. I think, this is it - the translations are UTF-8 and they pass syntax check.
http://code.google.com/p/chamilo/source/detail?r=d825c902a982ae9a679bfc99d2f541288d80b8b6&repo=classic

You may consider this work as done. Tomorrow I will make some checks about UTF-8 and I would make small corrections if it is necessary.

#33

Updated by Ivan Tcholakov about 12 years ago

10583:09e632452c01 Tasks #620 and #627 - A "normal" export from CDA - final selective corrections for some language files.
http://code.google.com/p/chamilo/source/detail?r=09e632452c01f5029594c253e68858a2a82c68aa&repo=classic

See the attached pictures to have an idea about the goal achieved.

#34

Updated by Ivan Tcholakov about 12 years ago

10584:73663b8cacc7 Task #627 - Trying CDA as an ordinary user.
http://code.google.com/p/chamilo/source/detail?r=73663b8cacc74e0b4fed7feee081e36107abe488&repo=classic

Ok. I am done here.

#35

Updated by Hans De Bisschop about 12 years ago

Very nice job Ivan !

#36

Updated by Marko Kastelic about 12 years ago

Hi, Ivan.Would you be so nice and check my translations (slovenian). On the page with language file list, files are flaged like outdated, but if you check variables inside files, there is no variable checked as outdated. (check files begin with a* start with admin, agenda, announcements ....)

#37

Updated by Ivan Tcholakov about 12 years ago

After re-importing the files this "outdated" problem happened with all the languages. Let me call this "problem 5".

It is wrong logic in CDA that is visible when files are imported. I solved it partially (see about problem 4). Frankly saying, I had enough of this, so I am leaving the situation as it is.

I see two things to be done for solving the problem:
1. Raw SQL queries to be run on the server to mark all the files an all the variables as "verified".
2. The logic of CDA when importing files to be verified/corrected. I think, the author of this tool should do this.

#38

Updated by Sven Vanpoucke about 12 years ago

Hi Ivan

1) If you tell me which queries i need to run to get it good again, please let me know, then i'll execute it tomorrow on the server.
2) I can't really help you with the fix for the logic because i didn't write the "out of date" methods for the CDA, but maybe hans can help.

#39

Updated by Ivan Tcholakov about 12 years ago

1. Within the file .../chamilo/application/lib/cda/variable_translation.class.php there the following constants declared:

const STATUS_NORMAL = 1;
const STATUS_BLOCKED = 2;
const STATUS_OUTDATED = 3;

I would try then the following query (rename the table reference accordingly to that in your server):

UPDATE cda.cda_variable_translation SET `status`=1;

For sure this will fix all the Bulgarian translations to be "normal" (or "verified"). Maybe this would fix the problem Marko described, but I am not sure, we'll see.

2. Here is my guess. See .../chamilo/application/lib/cda/data_manager/database.class.php. I would check/revise the methods get_status_for_language() and get_status_for_language_pack(). It seems to me something is wrong with them.

After that, just in case I would check in the file .../chamilo/application/lib/cda/forms/variable_translation_browser_fileter_form.class.php the method get_filter_conditions(). Probably it is OK, but check it visually anyway.

#40

Updated by Hans De Bisschop about 12 years ago

Ivan,

The "outdated" functionality was discussed / requested here: http://support.chamilo.org/issues/580
It basically marks a translation as outdated whenever it is updated ... so an import would correctly trigger that specific piece of functionality whenever it overwrites a currently existing translation by something different from the current translation. The change you made effectively breaks that entire system. That obviouslly can't have been the point, so I'll have to revert that.

If I understand correctly you want to bypass this functionality "on demand" when importing. Should it be bypassed at all? I don't think so. It's only a "problem" right now because we've been doing some initial imports (and there were some problems with HTML entities and escapes from what I gather).

As for the status checks: as soon as any of the translations in a language / language pack is marked as outdated, the corresponding language / language pack is automatically also marked as outdated. If it helps avoid frustrations, I'm more then willing to add "verification" options (which would basically set the status for all translations to normal) for languages and language packs. Only for administrators / moderators though. As a general rule though, whenever a translation is updated to something different from current translation it should still be marked as outdated.

Or has something been misexplained / misinterpreted in translation? (No pun intended AT ALL)

#41

Updated by Ivan Tcholakov about 12 years ago

I am not quite interesting in this this "verified/outdated" feature.

Here is the situation of the Chamilo 1.8.x branch:

(55 - 1) languages X ~2300 variables = 124200 translations

Let us say we have 62100 translations, this is the half of all translations at the moment, not all languages are 100% translated.

Now, to fix my problem 4, I am marking a Bulgarian translation as verified. I am clicking on the icon, the "Confirm your choice" appears (clicking again). Then I would have to wait ... 11 seconds for page to respond. Give me 1 second more to understand what hapened. So, I would waste 12 seconds for marking a translation.

12 seconds X 2300 variables = 7,7 hours, a whole working day. This is the price I should have to pay for marking all the Bulgarian translations as "verified" after I re-imported them.

In http://support.chamilo.org/issues/580 it has not been discussed what happens when variables are initially imported or re-imported.

In the light of the calculations above I appeal to you to redefine the behaviour of the "status" property. Let nothing about "status" triggers when mass-operations using files are applied.

#42

Updated by Hans De Bisschop about 12 years ago

If anything mass-operations should be checked and double-checked even more given they have the potential to break everything. Importing / updating from a file is just as prone to errors as directly translating in the application.

At any rate, let's keep things constructive please. Rome wasn't built in a day ... and neither will the "perfect" translation tool.

#43

Updated by Yannick Warnier about 12 years ago

Seems like I'm putting my nose into this at the right time...

I'm actually not understanding the description of the feature #580 the same way as you, Hans, but I admit it isn't clear enough.

The whole logic should be to allow someone changing a language to decide that all languages depending on that variable should be updated. In my view, this doesn't apply to file imports, mostly because you will probably never import an English (the most used origin language) language file, simply because it is the first language you create, and so when you add a term it has no translation yet (so it is implicitely outdated in the translation).

As such, the idea (in my opinion and I'm still actively supporting that idea in that sense) is to offer the possibility to someone changing an English term to mark it as outdated. When someone translates from English to something else, the variables that have been outdated are marked differently for the translator (in the destination language). This serves the purpose of letting all translators know that an original language term has changed meaning (or, for example, that we changed "Dokeos" for "Chamilo", to be very specific).

But this should never mark the terms imported through a file, mostly because the terms imported are generally already based on something that has been outdated.

Well, anyway... I can understand Ivan is getting to the end of his forces (I was actually starting to wonder if he was sleeping at all), and I approve his remarks. I hope my explanation made it clearer.

Y.

#44

Updated by Hans De Bisschop about 12 years ago

Hmm ... I see ... but what should be done when someone's source language isn't English? Following the logic you propose, obviously someone translating from spanish to portuguese should be made aware of any changes to the spanish translations and then the portuguese translations should be marked outdated ...

Which would conflict with another translator who translates directly from english to portuguese and for whom nothing has changed. (basically because he translated directly from the source-source language, given that English is our base-language)

Given that translations aren't personal things I hope you can see where the problem would be in that. Or do we just mark every translation in any other language as outdated whenever the english variable translation is changed?

To quote Mr. Hardy:

Well, here's another nice mess you've gotten me into!

;-)

#45

Updated by Ivan Tcholakov about 12 years ago

Let me try something...

Sample specification
-------------------------

The base for determination of outdated terms should be English language only. Changes in English language come from developers, they assign the meaning that should be translated in all other languages.

English term change ---> Outdated state triggers for Spanish, Portuguese, ... (all languages except English).

For a translator from Spanish to Portuguese the situation could be arranged in three ways:

1. The translation page to be blocked (even the invoking icon to be blocked) with showing a text (a tooltip) "Yo can not translate from an outdated term".

2. When the translator enters in the page, it could start with "The term in Spanish is outdated. Use the English term to translate from." And the English term which brings the updated meaning is to be shown.

3. The third way is a combination of the previous two. In the table's column "Actions" the regular "Translate" icon is blocked and it has a label "Yo can not translate from an outdated term". By the side of it another, additional icon appears with a label "Translate from English". If the translator knows how to translate from English anyway, he/she may have benefit from this option, otherwise he/she should wait Spanish translation to change its status to "verified" ("normal").

What has been described so far is two-state logic (outdated/verified). It is not clear to me whether the third state "blocked" changes something in the described above behaviour. With this third state "blocked" the specification should be extended.

#46

Updated by Ivan Tcholakov about 12 years ago

Sample specification, continuation for importing translations
----------------------------------------------------------------

Importing a file affects a selected branch only (Classic 1.8.x or Futura 2.x). A file being imported is a zip archive withe following internal structure:

english/ (folder name is the correspondent language idenyificator)
accessibility.inc.php (selected language files that are targeted for change)
admin.inc.php
...
spanish/
...
portuguese/
...

Every language files contains terms in the corresponding language, using the php-syntax. Every term definition should start in a new line's beginning. An example for a language file to import:

$TermIdentificator1 = "This is human readable string 1";
$TermIdentificator2 = "This is human readable string 2";
$TermIdentificator3 = "This is human readable string 3";
...

Technically, every term definition starts in a new line with "$". Although the importing algorithm ignores php-comments, better avoid making files to import with comments inside.

Note: For the branch Classic 1.8.x all the defined variables should be strings only. In some old language files dropbox.inc.php there are arrays of string defined, but they are obsolete and useless.

When language files for English are imported, for every imported term comparison with its previous value in the database is made. If the compared values are different, for all the other language the correspondent term switches to "outdated" state. (Here a question raises: in this case what should happen with "blocked" terms?) When the compared English values are equal, no state changes are triggered for the other languages.

When non-English language files are imported, every "outdated" term accepts "verified" state. (And again, what happens with a blocked term in this situation?)

#47

Updated by Hans De Bisschop about 12 years ago

Thanks for the detailed analysis Ivan. I'll try and get back at you as soon as possible ... just a little busy right now. :)

#48

Updated by Yannick Warnier about 12 years ago

Let's clear things up even a bit more:

  • outdated (=modified) serves to indicate one term's meaning has been modified and, as such, its translations should be updated as well. It is an indicator for translators and in my opinion a very useful one (we have a very bad experience with "invisible" meaning changes).
  • blocked (=confirmed=fixed=validated) is an indicator that the manager of the current language decided that this term is the best possible translation for the term, and wants to avoid somebody modifying it. Of course, in case of the term being later outdated in the source language, it should be "unlocked" automatically.

I agree with Ivan that English should rule them all (speaking of "outdated" marker), so that might simplify everything. If the English term has been outdated, the same term in all languages should be marked as outdated. I think it is reasonable to accept this kind of limitation. After all, it all comes down to having the meaning of the original term being changed, which only happens when developers come and modify the meaning, as Ivan says.

For some reason, in the newly imported strings (in Spanish for example), all "\n", "\r" and "\t" have been transformed to "n", "r" and "t". Is this a side effect from the over-filtering of the import?

#49

Updated by Ivan Tcholakov about 12 years ago

I will check and fix damaged "\n", "\r" and "\t". This time I will do the fix manually, without scripts.

#50

Updated by Ivan Tcholakov about 12 years ago

By the way, there are two languages defined in CDA: euskera and basque. People should use basque for both branches. euskera should be deleted, it is an alias. When export of basque is done for the Chamilo 1.8.x branch, then the folder within the zip is renamed as euskera, for compatibility.

#51

Updated by Yannick Warnier about 12 years ago

I agree with the Basque >< Euskera.

When you say "I will do it manually", you mean on a command line, right? Because right now the CDA doesn't have a global search for language translations, or does it?

#52

Updated by Ivan Tcholakov about 12 years ago

I am making the corrections with Eclipse first. Then I will find by name in CDA the changed variables only for correcting them, they are not so many, actually. The boring thing is that I have to subscribe to all the languages again. :-) Then I will make an export and I will compare to the changes made I Eclipse to see whether corrections are Ok.

Tomorrow I will delete from CDA euskera language. Basque language will stay, it is the same.

Also, I suggest we to delete from the repository code all the files htmlarea.js.php, they are not used for ages.

#53

Updated by Yannick Warnier about 12 years ago

OK. Note that some of the broken \r \n are easy to find by looking for "rn" or "nn". Some of them are more difficult. We could also look ourselves for the terms that used to contain \r or \n in the past and give you the list (I think that would make it easier).

#54

Updated by Yannick Warnier about 12 years ago

No problem for me to remove htmlarea-related files

#55

Updated by Ivan Tcholakov about 12 years ago

10608:c4aa6bbfe162 Task #627 - Chamilo 1.8.7: Purging obsolete language files.
http://code.google.com/p/chamilo/source/detail?r=c4aa6bbfe162309493cb473ac8bcc32fd78d1419&repo=classic

10607:653fbc9c4173 Task #627 - Chamilo 1.8.7: Language files update from CDA.
http://code.google.com/p/chamilo/source/detail?r=653fbc9c41739a1b046a5e60a92b45842610ef2e&repo=classic

#56

Updated by Ivan Tcholakov about 12 years ago

The file bbimport.inc.php is not used anywhere in Chamilo 1.8.7. Let us remove it, from CDA and from code?

#57

Updated by Ivan Tcholakov about 12 years ago

In the file dropbox.inc.php the array-type variable $dropbox_lang is defined. This array variable is not used in Chamilo 1.8.x, I suggest its correspondent records to be deleted from CDA. People should not translate them.

A correction about the previous message: The file bbimport.inc.php is not used anywhere in Chamilo 1.8.*x*. There is no problem it to be removed.

#58

Updated by Yannick Warnier about 12 years ago

I'm OK with the cleaning of phpbb-related files and the dropbox stuff (which as far as I know is the only occurence of an "array" of terms in the whole set of language files, and it's just a very bad idea).

#59

Updated by Ivan Tcholakov about 12 years ago

10657:98cd5ed126af Task #627 - Chamilo 1.8.7: Language files update - the obsolete array-type variable $dropbox_lang[] has been removed.
http://code.google.com/p/chamilo/source/detail?r=98cd5ed126af7b229363dda040edddda8f507cc1&repo=classic

In the code the obsolete files are more, not only that are mentioned before. They are not entered/supported by CDA. They are not used by the code, I checked this.

Here is the full list of files that I am going to purge:

bbimport.inc.php
forum_admin.inc.php
online_meeting.inc.php
phpbb.inc.php
survey_answer.inc.php
wcag.inc.php

Finally, I am going delete the temporay archive translations.zip, it contains old and dirty language data.

#60

Updated by Yannick Warnier about 12 years ago

I think wcag.inc.php is still used when the wcag option is enabled in the administration. This is a special feature for better accessibility of the Chamilo portal, so I think it shouldn't be removed. Other files should be free to remove (I have doubts for forum_admin.inc.php and survey_answer.inc.php, so please make sure they are not used anymore).

#61

Updated by Ivan Tcholakov about 12 years ago

I checked all of them, they are not used.
I am not going to delete wcag.inc.php so far. I seems to me that accessibility.inc.php plays its role...

#62

Updated by Ivan Tcholakov about 12 years ago

10661:04e83e0ab97f Task #627 - Chamilo 1.8.7, language files: Removing a temporary old archive with translations.
http://code.google.com/p/chamilo/source/detail?r=04e83e0ab97f47d11d8105efca2d9a74b90fae45&repo=classic

10660:c0162d572738 Task #627 - Chamilo 1.8.7, language files: Removing the obsolete file phpbb.inc.php.
http://code.google.com/p/chamilo/source/detail?r=c0162d572738e56dd3cff732709d8e2f9a75e295&repo=classic

10659:abd9f0c0f11a Task #627 - Chamilo 1.8.7, language files: Removing the obsolete file bbimport.inc.php.
http://code.google.com/p/chamilo/source/detail?r=abd9f0c0f11aef5e6687d96712aabb31583dd423&repo=classic

Although I checked that the files below are garbage, I decided not to delete them for now:

forum_admin.inc.php
online_meeting.inc.php
survey_answer.inc.php
wcag.inc.php

I think, there is no more work left here. This task may be closed.

#63

Updated by Ivan Tcholakov about 12 years ago

Ah, I've forgotten to mention something about the behaviour of the CDA-server. Maybe there is no accelerator activated on the server, APC. As of PHP 5.3 APC is activated by default.
It worths to try this option for better performance.

#64

Updated by Yannick Warnier about 12 years ago

A few of the variables in Spanish have been double-converted to UTF-8 and show square+questionmark unknown characters (the classical UTF-8 problem), but as far as I have seen this is a minor stuff and could be ignored (I think it only comes from >255 chars strings), so yes, the task could be closed. Let's leave it open for one more day.

I didn't know about APC enabled by default. Nice info.

#65

Updated by Ivan Tcholakov about 12 years ago

Yes, I see the problem with Spanish. I will fix it manually.

#66

Updated by Ivan Tcholakov about 12 years ago

A note: The meaning of $PlatformCharsetComment (admin.inc.php) to be changed for encouraging the organizations to choose UTF-8.

#67

Updated by Yannick Warnier about 12 years ago

And that's an excellent example of when a variable should be marked as "outdated" :-) (just in case someone would still have doubts)

#68

Updated by Ivan Tcholakov about 12 years ago

10662:546ced720811 Task #627 - Chamilo 1.8.7: Updating language files from CDA.
http://code.google.com/p/chamilo/source/detail?r=546ced720811542c7f6778f74a96dda543490427&repo=classic

#69

Updated by Ivan Tcholakov about 12 years ago

I have found that he former array $dropbox_lang is used in the code. I am going to restore its content as a series of string variables for about 37 languages.

#70

Updated by Ivan Tcholakov about 12 years ago

10762:04dcb0732f51 Task #627 - Chamilo 1.8.7: Updating language files from CDA.
http://code.google.com/p/chamilo/source/detail?r=04dcb0732f512203392f1ca159c31d12c0dc0f11&repo=classic

#72

Updated by Yannick Warnier about 12 years ago

From what I can remember, it means "Chamilo Download Application", mostly because it is planned to manage translations and plugins for Chamilo. Obviously all this is a little late on schedule, but the original idea was to have it ready at the same time as the beta of 2.0 so that people could start developing extensions/plugins and host them on the website.

#73

Updated by Sven Vanpoucke about 12 years ago

We will try to get the download part finished by the release of the beta. This relies heavily on our package manager since our website will become an external repository for the package manager and thus we will do this the last few days before the beta.

Edit: the original name comes from contribute and download application (it used to be DCDA => Dokeos contribute and download application. We removed the name of the product from it to be more transparent though.)

#74

Updated by Ivan Tcholakov almost 12 years ago

I suggest this task to be closed, it has been implemented.

#75

Updated by Yannick Warnier almost 12 years ago

  • Status changed from New to Feature implemented
  • % Done changed from 0 to 100
#76

Updated by Stefaan Vanbillemont about 11 years ago

  • Target version set to 2.1.0

Also available in: Atom PDF