Basic Language Translation Feature #66

Llewellyn · 2017-04-05T15:01:05Z

ro-ot commented

2017-04-05 15:01:05 +00:00

(Migrated from github.com)

This is the basic implementation, we can expand on this to insure the translation feature becomes a major improvement to JCB

mwweb (Migrated from github.com) reviewed 2017-04-05 15:01:05 +00:00

Llewellyn commented

2017-04-05 16:07:20 +00:00

Wow this has been fast, you really made a great effort here!

mwweb commented

2017-04-05 19:26:56 +00:00

(Migrated from github.com)

Going into the view the first time works. I added a translation, then after save received:

Table 'mysite_devsite.#__componentbuilder_components' doesn't exist SQL=SELECT name FROM #__componentbuilder_components WHERE id = 25

Going into the view the first time works. I added a translation, then after save received: Table 'mysite_devsite.#__componentbuilder_components' doesn't exist SQL=SELECT `name` FROM `#__componentbuilder_components` WHERE `id` = 25

ro-ot commented

2017-04-05 19:55:16 +00:00

(Migrated from github.com)

Okay I also had this error, but I fixed it, can you try this version and let me know if you still get the error.

Okay I also had this error, but I fixed it, can you try [this version](https://github.com/vdm-io/Joomla-Component-Builder/archive/d9b2e51f8c3e03ee1baeb566e14f7bea8f28c916.zip) and let me know if you still get the error.

Llewellyn commented

2017-04-05 20:04:47 +00:00

I also get this error when I create a new language from the translation view with the latest reviewed version.

View not found [name, type, prefix]: language_placeholder, html, componentbuilderView

I also get this error when I create a new language from the translation view with the latest reviewed version. ``` View not found [name, type, prefix]: language_placeholder, html, componentbuilderView ```

ro-ot commented

2017-04-05 20:09:25 +00:00

(Migrated from github.com)

Please note that the Language strings are added during compilation of a component at this time. I will look at these error reports.

But for you to see the English strings of a component, please first compile the component and then open the translations view or component view to see the auto generated values.

Please note that the Language strings are added during compilation of a component at this time. I will look at these error reports. But for you to see the English strings of a component, please first compile the component and then open the translations view or component view to see the auto generated values.

Llewellyn commented

2017-04-05 20:11:05 +00:00

I like the new warning notice that comes up before redirecting you away... nice if we can add this to more places 👍

I like the new warning notice that comes up before redirecting you away... nice if we can add this to more places :+1:

ro-ot (Migrated from github.com) reviewed 2017-04-05 20:21:07 +00:00

admin/helpers/compiler/f_Infusion.php

ro-ot (Migrated from github.com) commented

2017-04-05 20:21:07 +00:00

We only load a translation once it is at least 50% ready. @mwweb what do you think? should we make this a movable number, that can be set via the component or JCB global?

Llewellyn reviewed 2017-04-05 20:25:10 +00:00

admin/helpers/compiler/a_Get.php

						
				@ -2982,0 +3122,4 @@

										}

										else

										{

											$components = array($this->componentID);

Llewellyn commented

2017-04-05 20:25:10 +00:00

Wow this is a huge query... hmmm massive. More the 3000 strings.... but I don't see a better way. Just huge!

Llewellyn reviewed 2017-04-05 20:34:08 +00:00

admin/helpers/compiler/f_Infusion.php

Llewellyn commented

2017-04-05 20:34:08 +00:00

I think it can be a movable number per/component.

I think Joomla falls back to the default language if it can't find a string in the set language. Help me if I am wrong.

I think it can be a movable number per/component. I think Joomla falls back to the default language if it can't find a string in the set language. Help me if I am wrong.

mwweb commented

2017-04-05 20:44:38 +00:00

(Migrated from github.com)

Just as a thought... if debug in compiler is yes, it complies the language regardless of number. This might be good while testing. I'm not sure I'd need it that way, but there may be someone that would.

ro-ot commented

2017-04-06 07:30:32 +00:00

(Migrated from github.com)

@mwweb I need your feedback to continue the merge of this pull request. Are you still getting errors with this version?

On my side it is working well.

@mwweb I need your feedback to continue the merge of this pull request. Are you still getting errors with [this version](https://github.com/vdm-io/Joomla-Component-Builder/archive/d9b2e51f8c3e03ee1baeb566e14f7bea8f28c916.zip)? On my side it is working well.

ro-ot (Migrated from github.com) reviewed 2017-04-06 07:34:02 +00:00

admin/helpers/compiler/a_Get.php

						
				@ -2982,0 +3122,4 @@

										}

										else

										{

											$components = array($this->componentID);

ro-ot (Migrated from github.com) commented

2017-04-06 07:34:02 +00:00

Yes it is huge, but it works well. Mysql is a powerhouse 🥇

Yes it is huge, but it works well. Mysql is a powerhouse :1st_place_medal:

mwweb commented

2017-04-06 07:47:55 +00:00

(Migrated from github.com)

I can say that I didn't get that error. Beyond that, I need to figure out more how this is going to work

ro-ot commented

2017-04-06 07:59:16 +00:00

(Migrated from github.com)

During compilation it simple takes all the English strings and add them to the database, with the option for you to add multiple translated strings to each English string. IF you open a component you will see a new tab that also list all that component English strings, and the option to edit them one at a time.

Once all strings are translated to another language it will automatically add that new language to the component on compilation.

But wat is still need is an import function to speedup the translation feature. I mean to export the language (in English) and then to import for various languages. I will still build this.

But the basic feature is what we have now. So for now it is slow to do the translation. But when the export/import option is ready it will speedup the process. For then you can compile the component, and once all the English strings are in the database (after the compilation), you can export them in a txt file and update the placeholders and simply import the new language with that txt file, done. On next compilation the new language will be included.

Let me know if you can understand my explanation, and it you think it can work?

If you don't see any more errors, I will still add the features requested, and if all is good we can merge.

During compilation it simple takes all the English strings and add them to the database, with the option for you to add multiple translated strings to each English string. IF you open a component you will see a new tab that also list all that component English strings, and the option to edit them one at a time. Once all strings are translated to another language it will automatically add that new language to the component on compilation. But wat is still need is an import function to speedup the translation feature. I mean to export the language (in English) and then to import for various languages. I will still build this. But the basic feature is what we have now. So for now it is slow to do the translation. But when the export/import option is ready it will speedup the process. For then you can compile the component, and once all the English strings are in the database (after the compilation), you can export them in a txt file and update the placeholders and simply import the new language with that txt file, done. On next compilation the new language will be included. Let me know if you can understand my explanation, and it you think it can work? If you don't see any more errors, I will still add the features requested, and if all is good we can merge.

ro-ot (Migrated from github.com) reviewed 2017-04-06 08:12:34 +00:00

admin/helpers/compiler/f_Infusion.php

ro-ot (Migrated from github.com) commented

2017-04-06 08:12:34 +00:00

Can we just add it as a global setting instead of per/component? That seems much easier to do at this point. Then to force the language to be added we can use the debug switch as @mwweb suggested.

Llewellyn reviewed 2017-04-06 08:44:31 +00:00

admin/helpers/compiler/f_Infusion.php

Llewellyn commented

2017-04-06 08:44:31 +00:00

Yes I think that can work, not sure if joining the debug lines and the force load of languages is going to be an expected result. But lets do it like that for now, we can always improve on this later.

Llewellyn approved these changes 2017-04-06 08:55:53 +00:00

mwweb commented

2017-04-06 18:31:57 +00:00

(Migrated from github.com)

I guess one question on this...

When you compile, it populates #__componentbuilder_language_translation with found language strings.

If you are still developing, and add some additional language strings, or even change the translation in JCB. Does this new code scan and add new strings that are found, or update existing strings if they have been changed?

I guess one question on this... When you compile, it populates #__componentbuilder_language_translation with found language strings. If you are still developing, and add some additional language strings, or even change the translation in JCB. Does this new code scan and add new strings that are found, or update existing strings if they have been changed?

ro-ot commented

2017-04-06 20:14:51 +00:00

(Migrated from github.com)

At this time it adds the new/updated string if it can't be found. Mainly because it does not keep record of the placeholders, since the placeholders are very confusing between components. So the choice was between each component having its own strings, and not string sharing among component or developers, or strings sharing among component and developers (in the long run)

So if you change the string on a field description or label at this time, then it will create a new entry for the changed string, that string will not have the previous translated values, this makes most sense since the string changed in English it should change in every other language.

I think the feature can still be improved with some smart dynamic concepts, so share any ideas you may have to improve the current implementation.

I know @Llewellynvdm likes automation that borders on AI.

At this time it adds the new/updated string if it can't be found. Mainly because it does not keep record of the placeholders, since the placeholders are very confusing between components. So the choice was between each component having its own strings, and not string sharing among component or developers, or strings sharing among component and developers (in the long run) So if you change the string on a field description or label at this time, then it will create a new entry for the changed string, that string will not have the previous translated values, this makes most sense since the string changed in English it should change in every other language. I think the feature can still be improved with some smart dynamic concepts, so share any ideas you may have to improve the current implementation. I know @Llewellynvdm likes automation that borders on AI.

ro-ot commented

2017-04-06 20:34:29 +00:00

(Migrated from github.com)

If you change the translations of another language it will on the next build use that new translated string for that given language.

You will see that you can not change the English string in the Translation manager. So the English string can only be changed at the view, field or JText::_('string') value in the custom code around the JCB.

But adding more translations to a string will not effect the English string. On compilation of the component, it first builds all the English strings then it checks it they are in the Database then it starts building the placeholders for each language then it updates the strings to be linked to this component and add the new strings and finally adds the strings and files to the component and its XML.

Check out the links above, they point to the code in the compiler that does all the work.

If you change the translations of another language it will on the next build use that new translated string for that given language. You will see that you can not change the English string in the _Translation manager_. So the English string can only be changed at the view, field or `JText::_('string')` value in the custom code around the JCB. But adding more translations to a string will not effect the English string. On compilation of the component, it first builds all the [English strings](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1098) then it [checks]([url](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1100)) it they are [in the Database](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php#L3028) then it [starts building the placeholders](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1102) for [each language](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php#L3066) then it [updates the strings to be linked to this component](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php#L3109) and [add the new strings](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/a_Get.php#L3147) and finally [adds the strings](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1106) and [files](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1150) to the component and its [XML](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1171). Check out the links above, they point to the code in the compiler that does all the work.

Llewellyn commented

2017-04-06 20:46:57 +00:00

Hey don't drag me into this... you guys started this. So if you want it better make is better :)

But really I think the way it works now is much better then before, and it can with some smart import (to add more translations to the English strings), smart export (to export the language strings of one component for easy translation), refresh (to scan the components for new language strings) and purge (to remove language strings not longer in use) buttons become an amazing feature.

What I will do is link it to the export and import feature of components, so you can move it with the component to another JCB install.

I am very surprised at how fast you did this, thank you!

Hey don't drag me into this... you guys started this. So if you want it better make is better :) But really I think the way it works now is much better then before, and it can with some **smart import** (_to add more translations to the English strings_), **smart export** (_to export the language strings of one component for easy translation_), **refresh** (_to scan the components for new language strings_) and **purge** (_to remove language strings not longer in use_) buttons become an amazing feature. What I will do is link it to the _export and import feature of components_, so you can move it with the component to another JCB install. I am very surprised at how fast you did this, thank you!

mwweb commented

2017-04-06 22:05:55 +00:00

(Migrated from github.com)

I, too, am surprised at how quickly this came together.

On the above, "At this time it adds the new/updated string if it can't be found", we may want to improve that in future. I can see some "issues" with database bloat, especially during development. As an example, let's say I created a field, with a label of "Street". Then, I went an changed that to "Address". I now have 2 fields in the table, but only one is "legitimate". Then, if I change it again to "Street Address", I have how 3 fields in the table, but with only one as "legitimate".

The import feature, if it can be figured out, I would would streamline the language process, especially for the first time. Just as an example, on the Demo component, which is a really simple component, there are 240 language strings. This could, in theory, take a long time to process. But, at least it's doable.

I, too, am surprised at how quickly this came together. On the above, "At this time it adds the new/updated string if it can't be found", we may want to improve that in future. I can see some "issues" with database bloat, especially during development. As an example, let's say I created a field, with a label of "Street". Then, I went an changed that to "Address". I now have 2 fields in the table, but only one is "legitimate". Then, if I change it again to "Street Address", I have how 3 fields in the table, but with only one as "legitimate". The import feature, if it can be figured out, I would would streamline the language process, especially for the first time. Just as an example, on the Demo component, which is a really simple component, there are 240 language strings. This could, in theory, take a long time to process. But, at least it's doable.

Llewellyn commented

2017-04-06 23:04:58 +00:00

@mwweb JCB compiled load 3000+ strings to the DB so yes... that is why string sharing is the better way to go.

I think to add a purge button to remove strings no longer in use (due to changes in development), or even better the system can do that automatically for strings with not component linked to it, it can move them to trash, and then you can empty the trash every so often.

If I compile all the components I have the DB goes up the around 8000+ strings, and many are linked to more then 4 components, so the string sharing is working well with many components. But to translate 8000 strings will be a huge task.

So two main ideas need to be focused on to speed up translation:

We need to expand the translation feature to a community sharing idea.
Ensure an easy method of translation is found in the work-flow of JCB. Not change the structure, but to add easy export and import functions to expand on translations.

Lastly, I see only active English strings is used if I understand the code correctly. So to have JCB remove those inactive strings should not be to hard. We just need to check if any other components are using it, and if there is actually translation values already added.

IF it is used in other component just ignore and leave in place, just unlink from this component.
IF not used in other component but has translated values, archive or move to trash
IF none of the above, delete completely.

This can be added to compilation, or automation of service task.

@mwweb JCB compiled load 3000+ strings to the DB so yes... that is why string sharing is the better way to go. I think to add a purge button to remove strings no longer in use (due to changes in development), or even better the system can do that automatically for strings with not component linked to it, it can move them to trash, and then you can empty the trash every so often. If I compile all the components I have the DB goes up the around 8000+ strings, and many are linked to more then 4 components, so the string sharing is working well with many components. But to translate 8000 strings will be a huge task. So two main ideas need to be focused on to speed up translation: - We need to expand the translation feature to a community sharing idea. - Ensure an easy method of translation is found in the work-flow of JCB. Not change the structure, but to add easy export and import functions to expand on translations. Lastly, I see only active English strings is used if I understand the code correctly. So to have JCB remove those inactive strings should not be to hard. We just need to check if any other components are using it, and if there is actually translation values already added. IF it is used in other component just ignore and leave in place, just unlink from this component. IF not used in other component but has translated values, archive or move to trash IF none of the above, delete completely. This can be added to compilation, or automation of service task.

ro-ot commented

2017-04-07 05:45:53 +00:00

(Migrated from github.com)

I think that will be great, I see you already added the code for the Component export and import.

I will see when I can continue on this, since I have a few things that need my attention. You are welcome to expand on this 👍

I think that will be great, I see you already added the code for the Component export and import. I will see when I can continue on this, since I have a few things that need my attention. You are welcome to expand on this :+1:

Sign in to join this conversation.

No reviewers

mwweb