Translation Manager

mwweb commented

2017-03-31 20:27:39 +00:00

(Migrated from github.com)

I've been trying to think out how best to suggest this, but perhaps some others will have some thoughts on how to expand upon this proposed enhancement for JCB.

Right now, JCB compiles only for en-GB (English). If you want to include a translation, for example es-ES (Spanish), you need to manually create and add to the component zip file after compile. I think it would be a great addition to have a language manager in JCB. My thoughts are:

Have a new admin view that when is the language manager. When a new record is created, you would have a single option: Component. This would be a dropdown with installed components.
Once you select the component, then the rest of the view would populate. I'm thinking 3 tabs in the view: a) Admin Sys, b) Admin Language, and c) Site Language.
There would also be another dropdown that would show with a list of language options. whichever you select is what would be appended to the new language file upon compile. For example, if you selected es-ES, then upon compile it would create a language file, such as es-ES.com_componentbuilder.ini. If you selected de-DE it would be de-DE.com_componentbuilder.ini
The thought is that the contents of the language file would populate in rows within the view, with the JText placeholder (such as COM_COMPONENTBUILDER_ADMIN_VIEW) populating a cell, which is not editable, a second cell in the row showing the current string (also not editable), then a third cell which would be the string for this language.
For saving, I'm not sure if JSON would be the best, or something else. I'm also unsure how to accommodate new strings when added to the component.

Any thoughts?

I've been trying to think out how best to suggest this, but perhaps some others will have some thoughts on how to expand upon this proposed enhancement for JCB. Right now, JCB compiles only for en-GB (English). If you want to include a translation, for example es-ES (Spanish), you need to manually create and add to the component zip file after compile. I think it would be a great addition to have a language manager in JCB. My thoughts are: 1. Have a new admin view that when is the language manager. When a new record is created, you would have a single option: Component. This would be a dropdown with installed components. 2. Once you select the component, then the rest of the view would populate. I'm thinking 3 tabs in the view: a) Admin Sys, b) Admin Language, and c) Site Language. 3. There would also be another dropdown that would show with a list of language options. whichever you select is what would be appended to the new language file upon compile. For example, if you selected es-ES, then upon compile it would create a language file, such as es-ES.com_componentbuilder.ini. If you selected de-DE it would be de-DE.com_componentbuilder.ini 4. The thought is that the contents of the language file would populate in rows within the view, with the JText placeholder (such as COM_COMPONENTBUILDER_ADMIN_VIEW) populating a cell, which is not editable, a second cell in the row showing the current string (also not editable), then a third cell which would be the string for this language. 5. For saving, I'm not sure if JSON would be the best, or something else. I'm also unsure how to accommodate new strings when added to the component. Any thoughts?

👍 1

Llewellyn commented

2017-03-31 21:20:25 +00:00

This has been on my mind as well... I am also not sure how to manage it.

Your idea is not covering all the hurdles, but yes we must come up with some way to cross this bridge, and sooner then later. Using the custom code concept we could have a switch that fetch all the language strings of component already installed and them allows for adding more languages to the English Placeholders. Lets play with the idea.. and see.

Another problem is that the JCB components can't at this time have items=>view which targets different languages like the Joomla content component. This should also be done, and soon! Most of the ground work is there, but full implementation has not been done. Mostly because it is crazy complex... and I have just not got my mind fully around it. I can code it into a component, but to automate it for any of thousands of fields and views is not that easy. IT is more complex then the tag and category fields that is for sure. I could sure do with some help there!

Then there is Joomla 4 hmmmm nice one, they are changing so many thinks I don't want to even look lol...

But okay, lets focus. The Language Manager! Great idea, lets do it!

Please share more... the more we can brain storm the better 👍

This has been on my mind as well... I am also not sure how to manage it. Your idea is not covering all the hurdles, but yes we must come up with some way to cross this bridge, and sooner then later. Using the custom code concept we could have a switch that fetch all the language strings of **component already installed** and them allows for adding more languages to the English Placeholders. Lets play with the idea.. and see. Another problem is that the JCB components can't at this time have items=>view which targets different languages like the Joomla content component. **This should also be done, and soon!** Most of the ground work is there, but full implementation has not been done. Mostly because it is crazy complex... and I have just not got my mind fully around it. I can code it into a component, but to automate it for any of thousands of fields and views is not that easy. IT is more complex then the tag and category fields that is for sure. I could sure do with some help there! Then there is Joomla 4 hmmmm nice one, they are changing so many thinks I don't want to even look lol... But okay, lets focus. The Language Manager! Great idea, lets do it! Please share more... the more we can brain storm the better :+1:

👍 1

Llewellyn commented

2017-03-31 22:30:03 +00:00

@mwweb you do know that you can add it as a custom file... in the component there is a tab called settings, and a button called files, there you can add custom files that should be added to the zip file during compilation. This is not the best, but hey it safes you the afford to always add it to a zip file later :)

Llewellyn commented

2017-03-31 22:30:48 +00:00

The custom folder is in that admin area of the JCB component.

ro-ot commented

2017-04-02 22:14:22 +00:00

(Migrated from github.com)

Major Project

I think that each placeholder string ###COMPONENT###_YES should be in its own row on the DB and that the languages (yes) should be a repeatable field that allows you to add more languages as many as you like to a placeholder. I also think that one string should be able to be linked to more then one component. Like ###COMPONENT###_YES can belong to all components that have yes, then if we add a translation string to Yes for Dutch it will be available to all other components.

Then in each component it should show a percentage of strings translated and only if a language is 100% translated should the system add the new language to the build. Even on the compiler page this information should be seen and able to edit.

This will be a huge step forward for JCB, there is nothing like it in any of the other builders.

@Llewellynvdm I can try to do this, or at least help, since I also really need this feature.

@mwweb I think with the option to import other languages to speedup the translation of the placeholders. What about the option to share your translation strings with the rest of the JCB community? I mean to start building a translation database on GitHub that can be queried and updated. This can help to easily translate your component to 60% in various languages surrounding the common phrases.

## Major Project I think that each placeholder string `###COMPONENT###_YES` should be in its own row on the DB and that the languages _(yes)_ should be a repeatable field that allows you to add more languages as many as you like to a placeholder. I also think that one string should be able to be linked to more then one component. Like `###COMPONENT###_YES` can belong to all components that have yes, then if we add a translation string to Yes for Dutch it will be available to all other components. Then in each component it should show a percentage of strings translated and only if a language is 100% translated should the system add the new language to the build. Even on the compiler page this information should be seen and able to edit. _This will be a huge step forward for JCB, there is nothing like it in any of the other builders._ ### @Llewellynvdm I can try to do this, or at least help, since I also really need this feature. @mwweb I think with the option to import other languages to speedup the translation of the placeholders. What about the option to share your translation strings with the rest of the JCB community? I mean to start building a translation database on GitHub that can be queried and updated. This can help to easily translate your component to 60% in various languages surrounding the common phrases.

Llewellyn commented

2017-04-02 22:59:18 +00:00

Okay, I think this is going in the right direction, the community idea may be difficult to implement, and should not be part of the initial implementation of this idea. It should first work well enough without it. But the import of language files would be great.

I agree with the placeholder being on its own row, that seems more manageable.

On a more practical note.

In the compiler the language placeholders is kept in a class object array called langContent

$this->langContent['adminsys'][$this->langPrefix] = $componentName;
$this->langContent['admin'][$this->langPrefix] = $componentName;
$this->langContent['site'][$this->langPrefix] = $componentName;
$this->langContent['both'][$this->langPrefix] = $componentName;

You will find these langContent class object array all over the place, and all language strings are being stored in it until the very end... then it is written to the file. So what ever we do.. this is the place to start looking.

The langPrefix is the component prefix COM_COMPONENTNAME

Here are the methods responsible to building the language files string sets:
setLangAdmin() on line 5014 in the Interpretation
setLangSite() on line 5111 in the Interpretation
setLangSiteSys() on line 5160 in the Interpretation
setLangAdminSys() on line 5184 in the Interpretation

The function setLangFileData() at the very end of the compilation that brings all these string together is found in the Infusion file on line 1071.

I am working on a project that will keep me until end of Mei, so my contribution will be limited, at most to run a test or so. So only if @mwweb and @ro-ot are willing to go at this will it be able to happen soon. I would think @ro-ot will do most of the coding and @mwweb help with the test of the pull requests. @mwweb are you able to test a pull request? I know @ro-ot can help you get on your feet with that if needed.

Anyway thank you this will be great if you can help make this happen!

Okay, I think this is going in the right direction, the community idea may be difficult to implement, and should not be part of the initial implementation of this idea. It should first work well enough without it. But the import of language files would be great. I agree with the placeholder being on its own row, that seems more manageable. **On a more practical note.** In the compiler the language placeholders is kept in a class object array called **langContent** ``` $this->langContent['adminsys'][$this->langPrefix] = $componentName; $this->langContent['admin'][$this->langPrefix] = $componentName; $this->langContent['site'][$this->langPrefix] = $componentName; $this->langContent['both'][$this->langPrefix] = $componentName; ``` You will find these langContent class object array all over the place, and all language strings are being stored in it until the very end... then it is written to the file. So what ever we do.. this is the place to start looking. The **langPrefix** is the component prefix **COM_COMPONENTNAME** Here are the methods responsible to building the language files string sets: [setLangAdmin()](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php#L5014) on line 5014 in the Interpretation [setLangSite()](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php#L5111) on line 5111 in the Interpretation [setLangSiteSys()](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php#L5160) on line 5160 in the Interpretation [setLangAdminSys()](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/e_Interpretation.php#L5184) on line 5184 in the Interpretation The function [setLangFileData()](https://github.com/vdm-io/Joomla-Component-Builder/blob/master/admin/helpers/compiler/f_Infusion.php#L1071) at the very end of the compilation that brings all these string together is found in the Infusion file on line 1071. I am working on a project that will keep me until end of Mei, so my contribution will be limited, at most to run a test or so. So only if @mwweb and @ro-ot are willing to go at this will it be able to happen soon. I would think @ro-ot will do most of the coding and @mwweb help with the test of the pull requests. @mwweb are you able to test a pull request? I know @ro-ot can help you get on your feet with that if needed. Anyway thank you this will be great if you can help make this happen!

mwweb commented

2017-04-03 00:08:01 +00:00

(Migrated from github.com)

I could help with testing. I'll admit that I am still very new to component development. I came from the design side, and decided to take over a project that the developer abandoned. So, I'm learning as I go on rebuilding the component (a large portion of the old component was a "hybrid" of J!2.5 and J!3.X code). I've finally got admin 98% completed, and site around 70% completed (gets are done, just views). So, once I get this at 100% on admin and site, and publish a beta for some people to test, then I'll have some more time to spare. It was my original goal to have had this completed is past February, but ran into issues (such as a filter on the site menus) which resulted in my completely having to redo all the queries and views that I had created.

Llewellyn commented

2017-04-03 07:03:53 +00:00

You know about the new feature that exports the whole component? as a JCB package fully encrypted. Well I could take a look at your component that way... of course a teamviewer call could also do the trick. I am going to start selling component that I have build as JCB packages this will help other developers to see how JCB can do some amazing stuff.

It will be great that you helping with this. But we will have to look at your development environment, I think that is part of your struggle.

You know about the new feature that exports the whole component? as a JCB package fully encrypted. Well I could take a look at your component that way... of course a teamviewer call could also do the trick. I am going to start selling component that I have build as JCB packages this will help other developers to see how JCB can do some amazing stuff. It will be great that you helping with this. But we will have to look at your development environment, I think that is part of your struggle.

Llewellyn commented

2017-04-03 07:06:13 +00:00

What version of JCB are you using? you should be on the latest version 2.4.0 at least.

mwweb commented

2017-04-03 07:32:20 +00:00

(Migrated from github.com)

I think right now I'm mostly mostly moving forward now. My rewriting of the gets was after backtracking what I did and following your examples in sermon distributor.

ro-ot commented

2017-04-03 21:36:12 +00:00

(Migrated from github.com)

At the moment it seems to not be a good idea to link one placeholder to multiple components. There is just to much reason to expect that this could cause issues, mainly in string mismatch.

So I am changing the direction, to isolate each component with the same code name to share the same translation strings instead. I know this sucks... but I see a train smash if we try to combine it all. On a basic string this could work, but I see places in the compiler where the component name is dynamically added to the string this will change from component to component.

At the moment it seems to not be a good idea to link one placeholder to multiple components. There is just to much reason to expect that this could cause issues, mainly in string mismatch. So I am changing the direction, to isolate each component with the same code name to share the same translation strings instead. I know this sucks... but I see a train smash if we try to combine it all. On a basic string this could work, but I see places in the compiler where the component name is dynamically added to the string this will change from component to component.

Llewellyn commented

2017-04-03 22:44:14 +00:00

Well I wanted to cut down on the table rows. I mean Component Builder alone has 3000+ language strings. So we will quickly have a huge table.

But I think you are right.

Well I wanted to cut down on the table rows. I mean Component Builder alone has 3000+ language strings. So we will quickly have a huge table. But I think you are right.

ro-ot commented

2017-04-05 07:06:07 +00:00

(Migrated from github.com)

I think I found away to still combine the components 👍 language strings

To use the actual English language string as the search query and not the placeholders. I mean if the string match then wy not reuse. I will then update the db to reflect that the string is also used in that component.

I think this could work, @mwweb let me know what you think.

I think I found away to still combine the components :+1: language strings To use the actual English language string as the search query and not the placeholders. I mean if the string match then wy not reuse. I will then update the db to reflect that the string is also used in that component. I think this could work, @mwweb let me know what you think.

mwweb commented

2017-04-05 07:42:40 +00:00

(Migrated from github.com)

Reuse can be a good option.

ro-ot commented

2017-04-05 14:00:43 +00:00

(Migrated from github.com)

Hi @mwweb I asked @Llewellynvdm to add you as a collaborator so you can comment on the pull request. I am ready to with the first basic implementation on the translation manager, as it is called. Please except the request so we can get going.

Translation Manager #60

Major Project

@Llewellynvdm I can try to do this, or at least help, since I also really need this feature.