#198 - JText - other than the "_" method - Component-Builder

stutteringp0et commented

2017-12-12 23:00:54 +00:00

(Migrated from github.com)

This is more of a note than an issue - because the current extension does function in the prescribed manner - but it is missing a few pieces that I am accustomed to using.

I attempted to use JText::script('...') and found that it totally didn't work. If you haven't used it, the functionality inserts a translatable string into a javascript var in the output so your javascript can utilize translations via the Joomla.JText._('...') function. For strings that are only used in Javascript output, there isn't a facility to add these translations.

Any feedback would be welcome.

This is more of a note than an issue - because the current extension does function in the prescribed manner - but it is missing a few pieces that I am accustomed to using. I attempted to use JText::script('...') and found that it totally didn't work. If you haven't used it, the functionality inserts a translatable string into a javascript var in the output so your javascript can utilize translations via the Joomla.JText._('...') function. For strings that are only used in Javascript output, there isn't a facility to add these translations. Any feedback would be welcome.

Llewellyn commented

2017-12-12 23:20:52 +00:00

Hmmm yes at this time I have only targeted the two php options:

JText::_()
JText::sprintf()

You can see it done here on line 3110

I suppose we can add the JavaScript equivalent. I have not used it, I saw it in some of the core but I have not paid much attention to it at the time, as you can see over here from line 192

So give me some more info and we can add this options...

Hmmm yes at this time I have only targeted the two php options: ``` JText::_() JText::sprintf() ``` You can see it done here on line [3110](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/helpers/compiler/a_Get.php#L3110) I suppose we can add the JavaScript equivalent. I have not used it, I saw it in some of the core but I have not paid much attention to it at the time, as you can see over here from line [192](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/views/get_snippets/view.html.php#L192) So give me some more info and we can add this options...

stutteringp0et commented

2017-12-13 02:27:25 +00:00

(Migrated from github.com)

JText::script(...) works a lot like JText::(...), except the output isn't to the page where the JText method exists, it becomes part of a system JDocument::scriptOptions(...) call where all strings called by JText::script(...) are added to a javascript object delivered in the document head. Pretty much any J3.x page will contain a <script type="application/json"... and that object will contain an attribute named joomla.jtext which is used by the window.Joomla.JText. method to deliver translated strings to javascript on the page.

For the time being, I've been I've been assigning the strings to an unused array so they get assigned constants by JCB, and then later I re-write the script to use the constants in a JText::script(...) statement and rewrite the Javascript to use the correct constants. It's terribly inefficient.

JText::script(...) works a lot like JText::_(...), except the output isn't to the page where the JText method exists, it becomes part of a system JDocument::scriptOptions(...) call where all strings called by JText::script(...) are added to a javascript object delivered in the document head. Pretty much any J3.x page will contain a <script type="application/json"... and that object will contain an attribute named joomla.jtext which is used by the window.Joomla.JText._ method to deliver translated strings to javascript on the page. For the time being, I've been I've been assigning the strings to an unused array so they get assigned constants by JCB, and then later I re-write the script to use the constants in a JText::script(...) statement and rewrite the Javascript to use the correct constants. It's terribly inefficient.

stutteringp0et commented

2017-12-13 02:32:05 +00:00

(Migrated from github.com)

Yeah, I see that starting on 192 of the get_snippets view. I like to create an array of the unique portion of the constant and loop through it, prepending the prefix before calling JText::script(...)

Then in your javascript you can get your translated string with Joomla.JText._('COM_WHATEVER_CONSTANT')

That's giving me an eye twitch, so I may tackle that conversion soon.

Yeah, I see that starting on 192 of the get_snippets view. I like to create an array of the unique portion of the constant and loop through it, prepending the prefix before calling JText::script(...) Then in your javascript you can get your translated string with Joomla.JText._('COM_WHATEVER_CONSTANT') That's giving me an eye twitch, so I may tackle that conversion soon.

Llewellyn commented

2017-12-13 03:01:16 +00:00

Okay give me an example of how you will redo few of these and then I will adapt the compiler to also grab these and add them to the language files.

Okay give me an example of how you will redo [few of these](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/views/get_snippets/view.html.php#L192) and then I will adapt the compiler to also grab these and add them to the language files.

stutteringp0et commented

2017-12-13 03:12:05 +00:00

(Migrated from github.com)

OK, there's not really a reason to keep the javascript in that file - so I'd pull that out into a separate javascript and consolidate the jQuery(document).ready statements. Next I would replace all of the +lang_whatEVer+ with +Joomla.JText._('COM_COMPONENTBUILDER_WHATEVER')+

As a bonus, the quotes can be unescaped and the whole thing will be easier to maintain and debug.

Back in the PHP, the text strings would be added into an array like this:

$constants = array(
    'JCB_COMMUNITY_SNIPPETS',
    'SNIPPETS',
    'SNIPPET',
    'VIEW_SNIPPET_OF_COMMUNITY_VERSION',
    ....etc
);

Immediately afterwards, I would loop through the $constants array to send them to the front-end - that would look like this:

foreach($constants as $constant) {
    JText::script('COM_COMMUNITYBUILDER_'.$constant);
}

OK, there's not really a reason to keep the javascript in that file - so I'd pull that out into a separate javascript and consolidate the jQuery(document).ready statements. Next I would replace all of the +lang_whatEVer+ with +Joomla.JText._('COM_COMPONENTBUILDER_WHATEVER')+ As a bonus, the quotes can be unescaped and the whole thing will be easier to maintain and debug. Back in the PHP, the text strings would be added into an array like this: $constants = array( 'JCB_COMMUNITY_SNIPPETS', 'SNIPPETS', 'SNIPPET', 'VIEW_SNIPPET_OF_COMMUNITY_VERSION', ....etc ); Immediately afterwards, I would loop through the $constants array to send them to the front-end - that would look like this: foreach($constants as $constant) { JText::script('COM_COMMUNITYBUILDER_'.$constant); }

stutteringp0et commented

2017-12-13 03:14:45 +00:00

(Migrated from github.com)

I understand if things need to be different for the compiler - but still, pulling out the addScriptDeclarations in favor of addScript() and a bunch of JText::script() will simplify a lot.

stutteringp0et commented

2017-12-13 03:19:48 +00:00

(Migrated from github.com)

Looking further into that file, there is a lot more that could be made to use the JDocument::setOptions().

It's relatively new....since 3.5 I think - so a lot of scripts still use the old way... I still haven't converted all of my extensions to use the new way - but I've been focusing on J4 issues, so I can get a better feel for the new landscape. I'll be releasing J4 compatible versions of my extensions when J4 goes into beta and all of those will be using the new javascript methods.

Looking further into that file, there is a lot more that could be made to use the JDocument::setOptions(). It's relatively new....since 3.5 I think - so a lot of scripts still use the old way... I still haven't converted all of my extensions to use the new way - but I've been focusing on J4 issues, so I can get a better feel for the new landscape. I'll be releasing J4 compatible versions of my extensions when J4 goes into beta and all of those will be using the new javascript methods.

stutteringp0et commented

2017-12-13 04:51:38 +00:00

(Migrated from github.com)

I just finished testing modifications to /administrator/components/com_jcb/views/get_snippets/view.html.php

Everything is working fine, although I would like to turn the javascript into a class and push the javascript vars through the joomla controlled JSON object (via JDocument::setOptions). It's getting late and one success is good enough for tonight.

I've added a javascript and altered the above linked view.html.php so you can get a feel for how this looks and works. I chose not to complicate things with a constants loop - it really only saves typing anyway, it isn't any more efficient. You should see a PR for it.

I hadn't paid too much attention to the snippets until now - it's nice that all of the BS4 stuff is already there - that will come in handy for the J4 rollout. Is @ro-ot the one who did that?

I just finished testing modifications to /administrator/components/com_jcb/views/get_snippets/view.html.php Everything is working fine, although I would like to turn the javascript into a class and push the javascript vars through the joomla controlled JSON object (via JDocument::setOptions). It's getting late and one success is good enough for tonight. I've added a javascript and altered the above linked view.html.php so you can get a feel for how this looks and works. I chose not to complicate things with a constants loop - it really only saves typing anyway, it isn't any more efficient. You should see a PR for it. I hadn't paid too much attention to the snippets until now - it's nice that all of the BS4 stuff is already there - that will come in handy for the J4 rollout. Is @ro-ot the one who did that?

stutteringp0et commented

2017-12-13 05:00:30 +00:00

(Migrated from github.com)

The thing I think will be tricky for the compiler is that the constant is what's needed in the javascript, although it's injected into the <head> within PHP. The javascript needs to know the constant - so the problem will remain that the component must be compiled so the constants can be obtained and replaced into the javascript. Change one word in the PHP string and the constant changes and the javascript must be rewritten.

stutteringp0et commented

2017-12-13 07:11:29 +00:00

(Migrated from github.com)

Here's a thought - for text where the constant must be known in advance - a secondary translation construct could be used. Maybe something like:

JCBText::_('COM_WHATEVER_PREDEFINED_KNOWN_CONSTANT','Translated string')

This way, the compiler could utilize the pre-defined constant in translation files, replace JCBText with JText in the output PHP and just remove the 'Translated string' from the parsed text. It would be backwards compatible.

Here's a thought - for text where the constant must be known in advance - a secondary translation construct could be used. Maybe something like: JCBText::_('COM_WHATEVER_PREDEFINED_KNOWN_CONSTANT','Translated string') This way, the compiler could utilize the pre-defined constant in translation files, replace JCBText with JText in the output PHP and just remove the 'Translated string' from the parsed text. It would be backwards compatible.

Llewellyn commented

2017-12-13 21:50:42 +00:00

Okay I see two concepts that must lineup the JText::script('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED'); in the php with Joomla.JText._('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED') in the JavaScript and what must match is COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED have I understood that correctly?

IF yes, then here is how JCB works you give it JText::_('An error has occurred'); and it builds JText::_('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED'); and adds the translation string to the language files. So never need to worry about the constant it deals with it for you.

So in theory that means I can adapt JCB to also target JText::script() and Joomla.JText._() and treat them the same as it already does the JText::_() the only tricky part I see is that you will need to insure that both have the same translation sting.

So it should look like this:
JText::script('An error has occurred');
Joomla.JText._('An error has occurred')
Then JCB wil produce:
JText::script('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED');
Joomla.JText._('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED')

But if you make a spelling mistake between them then they will not line up and it will not work.

Let me know if I understood that correctly. To implement this will be very easy and immediately add the same behavior to this feature as we already have with JText::_()

Okay I see two concepts that must lineup the `JText::script('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED');` in the php with `Joomla.JText._('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED')` in the JavaScript and what must match is `COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED` have I understood that correctly? IF yes, then here is how JCB works you give it `JText::_('An error has occurred');` and it builds `JText::_('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED');` and adds the translation string to the language files. So never need to worry about the constant it deals with it for you. So in theory that means I can adapt JCB to also target `JText::script()` and `Joomla.JText._()` and treat them the same as it already does the `JText::_()` the only tricky part I see is that you will need to insure that both have the same translation sting. So it should look like this: `JText::script('An error has occurred');` `Joomla.JText._('An error has occurred')` Then JCB wil produce: `JText::script('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED');` `Joomla.JText._('COM_COMPONENTBUILDER_AN_ERROR_HAS_OCCURRED')` But if you make a spelling mistake between them then they will not line up and it will not work. Let me know if I understood that correctly. To implement this will be very easy and immediately add the same behavior to this feature as we already have with `JText::_()`

stutteringp0et commented

2017-12-13 21:56:38 +00:00

(Migrated from github.com)

That's exactly it.

So if you were to change the PHP JText::script(), you would have to find all matching Joomla.JText._() and update them to the corrected string.

Something that I've been meaning to bring up though, is the fact that any change in the translation output changes the language constant. This precludes any meaningful efforts at translating a language file, as even a simple change to the original language string invalidates the previously used constant.

It would be great if there was a way to predefine the constant (see my JCBText::_ comment above). With something like that, the constants could remain constant.

That's exactly it. So if you were to change the PHP JText::script(), you would have to find all matching Joomla.JText._() and update them to the corrected string. Something that I've been meaning to bring up though, is the fact that any change in the translation output changes the language constant. This precludes any meaningful efforts at translating a language file, as even a simple change to the original language string invalidates the previously used constant. It would be great if there was a way to predefine the constant (see my JCBText::_ comment above). With something like that, the constants could remain constant.

Llewellyn commented

2017-12-13 22:04:23 +00:00

I am not sure I understand the problem, I did look at your JCBText:: comment above, and could see some of the logic, my point is the constant is build from the translation string and JCB does all that for you, so if you change the language string in both places it will update it correctly.

When it comes to adding more languages, the constant does not change. I mean adding more translations it still will use the same constant, since in JCB you should always only use English and for other languages use the translation manager. That is how it works for now anyway.

What am I missing here, or is it something you don't yet see.... hmmm I am not sure, but I think we are close.

I am not sure I understand the problem, I did look at your JCBText:: comment above, and could see some of the logic, my point is the constant is build from the translation string and JCB does all that for you, so if you change the language string in both places it will update it correctly. When it comes to adding more languages, the constant does not change. I mean adding more translations it still will use the same constant, since in JCB you should always only use English and for other languages use the translation manager. That is how it works for now anyway. What am I missing here, or is it something you don't yet see.... hmmm I am not sure, but I think we are close.

Llewellyn commented

2017-12-13 22:05:36 +00:00

Is the issue that you don't want to maintain two language strings?

Llewellyn commented

2017-12-13 22:23:27 +00:00

There is one little notice we could add to the compiler so the developer will at least know if a mismatch is found, it will not be waterproof but it will be the closes to heads-up we will get. What I can do is I can keep track of Joomla.JText._('A_STRING') and make sure that it at least has one JText::script('A_STRING') association/partner in the same view and if not the compiler can give you a notice that that string no longer have a matching relationship and will not work.

This way you will at least know if you did not do thing correctly, and be able to open that view and fix the issue.

There is one little notice we could add to the compiler so the developer will at least know if a mismatch is found, it will not be waterproof but it will be the closes to heads-up we will get. What I can do is I can keep track of `Joomla.JText._('A_STRING')` and make sure that it at least has one `JText::script('A_STRING')` association/partner in the same view and if not the compiler can give you a notice that that string no longer have a matching relationship and will not work. This way you will at least know if you did not do thing correctly, and be able to open that view and fix the issue.

Llewellyn commented

2017-12-13 22:27:28 +00:00

Tell me if this can server as a start... 👍 I mean let me implement this and then we can test it and see if the behavior is as expected and if it achieves the objective.

Tell me if this can server as a start... :+1: I mean let me implement this and then we can test it and see if the behavior is as expected and if it achieves the objective.

stutteringp0et commented

2017-12-13 22:30:49 +00:00

(Migrated from github.com)

I think there's a misunderstanding here.

If I compile a component that uses this in one of the views:
JText::script('Some Text')

and this in the javascript:
Joomla.JText._('Some Text')

The result in both will become (respectively):
JText::script('COM_WHATEVER_SOME_TEXT')
Joomla.JText._('COM_WHATEVER_SOME_TEXT')

At this point, if I hire someone to translate it to Spanish, they're going to be assigning Spanish translation to the constant:
COM_WHATEVER_SOME_TEXT="yo quiero taco bell"

If I adjust the text in the component:
JText::script('Some New Text')

and the javascript:
Joomla.JText._('Some New Text')

The compiled result becomes (respectively)
JText::script('COM_WHATEVER_SOME_NEW_TEXT')
Joomla.JText._('COM_WHATEVER_SOME_NEW_TEXT')

Now the Spanish translation file must be repaired

I just re-compiled something to test this (using JText::_()) - and that's how it seems to work

<?php echo JText::_('COM_FAVICON_SOME_TEXT'); ?>
<?php echo JText::_('COM_FAVICON_SOME_OTHER_TEXT'); ?>

became

<?php echo JText::_('COM_FAVICON_SOME_NEW_TEXT'); ?>
<?php echo JText::_('COM_FAVICON_SOME_OTHER_NEW_TEXT'); ?>

I think there's a misunderstanding here. If I compile a component that uses this in one of the views: JText::script('Some Text') and this in the javascript: Joomla.JText._('Some Text') The result in both will become (respectively): JText::script('COM_WHATEVER_SOME_TEXT') Joomla.JText._('COM_WHATEVER_SOME_TEXT') At this point, if I hire someone to translate it to Spanish, they're going to be assigning Spanish translation to the constant: COM_WHATEVER_SOME_TEXT="yo quiero taco bell" If I adjust the text in the component: JText::script('Some New Text') and the javascript: Joomla.JText._('Some New Text') The compiled result becomes (respectively) JText::script('COM_WHATEVER_SOME_NEW_TEXT') Joomla.JText._('COM_WHATEVER_SOME_NEW_TEXT') Now the Spanish translation file must be repaired I just re-compiled something to test this (using JText::_()) - and that's how it seems to work <?php echo JText::_('COM_FAVICON_SOME_TEXT'); ?> <?php echo JText::_('COM_FAVICON_SOME_OTHER_TEXT'); ?> became <?php echo JText::_('COM_FAVICON_SOME_NEW_TEXT'); ?> <?php echo JText::_('COM_FAVICON_SOME_OTHER_NEW_TEXT'); ?>

stutteringp0et commented

2017-12-13 22:37:49 +00:00

(Migrated from github.com)

I'm not trying to be difficult - I understand what you're trying to do with the automatic constant creation. It takes out a step. For me, it's kind of frustrating to have no control over the language constants. If my customer wants a language change - I might have to do significant work because not only does it change everywhere the particular string is used, but now I must take note of the previous constant and replace it with the new constant in all of the translation files.

The only customer I've used JCB for is an aviation company - and the international standard for aviation is English....so I'm safe with their extension. I can't say that for any of my other customers though.

I'm not trying to be difficult - I understand what you're trying to do with the automatic constant creation. It takes out a step. For me, it's kind of frustrating to have no control over the language constants. If my customer wants a language change - I might have to do significant work because not only does it change everywhere the particular string is used, but now I must take note of the previous constant and replace it with the new constant in all of the translation files. The only customer I've used JCB for is an aviation company - and the international standard for aviation is English....so I'm safe with their extension. I can't say that for any of my other customers though.

Llewellyn commented

2017-12-13 22:41:59 +00:00

Yes because of the nature of languages it just seemed impossible to avoid that. So for each English string (your example) Some Text there is in the translation manager a item created, so if the string changes naturally there is a new English string and it gets to create an new item.

To me that seems the be expected since if you made changes to the English version, then need to also adapt the other languages may be required and anyway how will we else be able to manage that.

What I am working on is the option to export the translation strings into a CSV or JSON... still looking around for a tool that can server as a sharing translations for open-source projects, like we did with the snippets. So we can easy export all language strings, add it to this community translation project and then once we have all the translations done in this community "place" we import it back into JCB via JSON or CSV whatever will work best and this way speedup the translations. But that is another topic and issue altogether.

I know you are not try to be difficult, but hey JCB builds all the language files for you (even for other languages)... have you looked at the translation manager in JCB? It is a powerful tool that links translations of stings across all your components, truly an area that if we expand it to the above mentioned idea it will make JCB the very best component builder for years to come... lol

Yes because of the nature of languages it just seemed impossible to avoid that. So for each English string (your example) **Some Text** there is in the translation manager a item created, so if the string changes naturally there is a new English string and it gets to create an new item. To me that seems the be expected since if you made changes to the English version, then need to also adapt the other languages may be required and anyway how will we else be able to manage that. What I am working on is the option to export the translation strings into a CSV or JSON... still looking around for a tool that can server as a sharing translations for open-source projects, like we did with the snippets. So we can easy export all language strings, add it to this community translation project and then once we have all the translations done in this community "place" we import it back into JCB via JSON or CSV whatever will work best and this way speedup the translations. But that is another topic and issue altogether. I know you are not try to be difficult, but hey JCB builds all the language files for you (even for other languages)... have you looked at the translation manager in JCB? It is a powerful tool that links translations of stings across all your components, truly an area that if we expand it to the above mentioned idea it will make JCB the very best component builder for years to come... lol

Llewellyn commented

2017-12-13 22:45:23 +00:00

We could add improvements to the translation manger to address this, maybe allow you to dynamically copy language strings from other languages to the new English string, but I will need to sleep on that one since it is crazy stuff... but I can see the possibility to do that.

stutteringp0et commented

2017-12-13 22:45:42 +00:00

(Migrated from github.com)

I have seen it. But it isn't really useful to me. I would send an english ini file to be translated and receive a spanish or whatever ini file back. I would never grant a translator access to any of my sites. They get ini files and screenshots (if necessary).

As far as requiring re-translation for an english language change - it might be something as simple as a typo in english - but that typo changes the constant and now all of the translations for the typo constant are invalid.

I have seen it. But it isn't really useful to me. I would send an english ini file to be translated and receive a spanish or whatever ini file back. I would never grant a translator access to any of my sites. They get ini files and screenshots (if necessary). As far as requiring re-translation for an english language change - it might be something as simple as a typo in english - but that typo changes the constant and now all of the translations for the typo constant are invalid.

Llewellyn commented

2017-12-13 22:47:21 +00:00

Hey the CSV or JSON will never be anything other then the same information you will find in the ini file, so you still will not need to expose your work.

stutteringp0et commented

2017-12-13 22:48:26 +00:00

(Migrated from github.com)

Yes, that idea I can get on board with! CSV would make it pretty easy to find and replace altered constants.

Llewellyn commented

2017-12-13 22:49:58 +00:00

Yes I understand the typo issue (hate it when that happens), but believe me when you have 6033 language strings like JCB you cheer that it does all the constants for you.

Yes I understand the typo issue (hate it when that happens), but believe me when you have [6033](https://github.com/vdm-io/Joomla-Component-Builder/blob/staging/admin/language/en-GB/en-GB.com_componentbuilder.ini#L6033) language strings like JCB you cheer that it does all the constants for you.

Llewellyn commented

2017-12-13 22:53:35 +00:00

And you must know where I could set a more constant, constant I did like in the fields I use _LABEL and _DESCRIPTION and _HINT to try and bring some notion that if you fix a field label but you do not change the name, the language constant does not change.

stutteringp0et commented

2017-12-13 22:54:59 +00:00

(Migrated from github.com)

I don't understand

Llewellyn commented

2017-12-13 23:08:53 +00:00

The fields have some strings that get translated right, well I use the name to build those constant not the strings, so if the field name is lets say name="name" and it is used in Joomla Component view the language constants will look like this:

COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_DESCRIPTION="Enter Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_HINT="Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_LABEL="Name"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_MESSAGE="Error! Please add name here."

So if you change lets say the description to Enter Your Name Here and the label to Your Name it will look like this.

COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_DESCRIPTION="Enter Your Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_HINT="Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_LABEL="Your Name"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_MESSAGE="Error! Please add name here."

Only if you change the field name to name="bname" will it change the constant to

COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_DESCRIPTION="Enter Your Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_HINT="Name Here"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_LABEL="Your Name"
COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_MESSAGE="Error! Please add name here."

Also if you change the View name to A Component it will become

COM_COMPONENTBUILDER_A_COMPONENT_NAME_DESCRIPTION="Enter Your Name Here"
COM_COMPONENTBUILDER_A_COMPONENT_NAME_HINT="Name Here"
COM_COMPONENTBUILDER_A_COMPONENT_NAME_LABEL="Your Name"
COM_COMPONENTBUILDER_A_COMPONENT_NAME_MESSAGE="Error! Please add name here."

The idea is to try and avoid changes to the name and the view name unless it is absolutely needed. Most cases I have never needed to do that, unless we have a major change, and then it is usually understood by the clients that the change will cost them more.

The is only in relation the the fields at this time, we could look at other areas where we can do more of that, but believe me it is hard to do and keep track of in an automated way.

The fields have some strings that get translated right, well I use the name to build those constant not the strings, so if the field name is lets say `name="name"` and it is used in **Joomla Component** view the language constants will look like this: ``` COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_DESCRIPTION="Enter Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_HINT="Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_LABEL="Name" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_MESSAGE="Error! Please add name here." ``` So if you change lets say the description to **Enter Your Name Here** and the label to **Your Name** it will look like this. ``` COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_DESCRIPTION="Enter Your Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_HINT="Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_LABEL="Your Name" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_NAME_MESSAGE="Error! Please add name here." ``` Only if you change the field name to `name="bname"` will it change the constant to ``` COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_DESCRIPTION="Enter Your Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_HINT="Name Here" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_LABEL="Your Name" COM_COMPONENTBUILDER_JOOMLA_COMPONENT_BNAME_MESSAGE="Error! Please add name here." ``` Also if you change the View name to **A Component** it will become ``` COM_COMPONENTBUILDER_A_COMPONENT_NAME_DESCRIPTION="Enter Your Name Here" COM_COMPONENTBUILDER_A_COMPONENT_NAME_HINT="Name Here" COM_COMPONENTBUILDER_A_COMPONENT_NAME_LABEL="Your Name" COM_COMPONENTBUILDER_A_COMPONENT_NAME_MESSAGE="Error! Please add name here." ``` The idea is to try and avoid changes to the name and the view name unless it is absolutely needed. Most cases I have never needed to do that, unless we have a major change, and then it is usually understood by the clients that the change will cost them more. The is only in relation the the fields at this time, we could look at other areas where we can do more of that, but believe me it is hard to do and keep track of in an automated way.

Llewellyn commented

2017-12-13 23:32:16 +00:00

But yes in the language manager we do not work with constants but only with English strings, painful as that is, there is no other way to do it. Believe me the constants does not work, when we build that area it was like running into a nightmare because of the amazing complexity of language and how the constants does not always communicate the same in every view, and yet we wanted to insure that if you translated "Name" once you never need to translate it ever again for another component or view. and the only way to achieve this was to work directly with the actual English string as the identifier. Did you know that if JCB detects that a English language string is no longer linked to any component and has no translation it automatically removes it. IF it does have translation values, it archives it, seeing it is no longer linked to a component.

Well anyway this is my first try, and so far it has proven to work extremely well for me. I think the improve the ease of the translation manger with the CSV and stuff is the future on this subject.

As for the current issue at hand I will continue down the path of the proposed implementation.

But yes in the language manager we do not work with constants but only with English strings, painful as that is, there is no other way to do it. Believe me the constants does not work, when we build that area it was like running into a nightmare because of the amazing complexity of language and how the constants does not always communicate the same in every view, and yet we wanted to insure that if you translated "**Name**" once you never need to translate it ever again for another component or view. and the only way to achieve this was to work directly with the actual English string as the identifier. Did you know that if JCB detects that a English language string is no longer linked to any component and has no translation it automatically removes it. IF it does have translation values, it archives it, seeing it is no longer linked to a component. Well anyway this is my first try, and so far it has proven to work extremely well for me. I think the improve the ease of the translation manger with the CSV and stuff is the future on this subject. As for the current issue at hand I will continue down the path of the proposed implementation.

stutteringp0et commented

2017-12-13 23:58:08 +00:00

(Migrated from github.com)

I have to ask, how are your changes to the compiler going to affect the simplexml conversion I've been working on? I'm about 80% done. How does that merge work?

Llewellyn commented

2017-12-14 02:17:35 +00:00

Please make the pull request to the simplexml branch and we will take if from there. It should not effect each other, but one never knows for sure until we have the code. I will push to the staging branch and we will merge those once all is tested and ready.

stutteringp0et commented

2017-12-14 04:48:46 +00:00

(Migrated from github.com)

I saw the simplexml branch, which is why I started on it today.

I'm adding [TODO] comments where I'm finding untranslated strings - should I mark obvious typos too? Some are field names, so I don't want to change them - marking them seems to be a good idea though.

I saw the simplexml branch, which is why I started on it today. I'm adding [TODO] comments where I'm finding untranslated strings - should I mark obvious typos too? Some are field names, so I don't want to change them - marking them seems to be a good idea though.

Llewellyn commented

2017-12-14 11:09:08 +00:00

In the compiler we have many strings specially as for notices that are not converted to constants because the compiler can't parse the compiler and I have not yet adapted the compiler to inject our own translated strings. Reality is if I passed the compiler into the compiler it will break it completely, I tried.. so grabbing all the translation strings from it, is something I would still need to fix.

With regards to typos, hey you should know that I can not spell at all. Call it my handicap so the fact that anything is spelled correctly is absolutely amazing, and mostly the help of my spell checker all around, and my personal editors (Wife, Children, Friends and Colleagues).

When it comes to typos in the name field, hmmm please point them out to me and I will make the call.

Okay so if you see a spelling mistake please make a pull request to the staging branch with a clear git comment just targeting those, I would like to separate the two things. I mean improvements to format and typos from logic and improvements to the compiler it self.

In the compiler we have many strings specially as for notices that are not converted to constants because the compiler can't parse the compiler and I have not yet adapted the compiler to inject our own translated strings. Reality is if I passed the compiler into the compiler it will break it completely, I tried.. so grabbing all the translation strings from it, is something I would still need to fix. With regards to typos, hey you should know that I can not spell at all. Call it my handicap so the fact that anything is spelled correctly is absolutely amazing, and mostly the help of my spell checker all around, and my personal editors (Wife, Children, Friends and Colleagues). When it comes to typos in the name field, hmmm please point them out to me and I will make the call. Okay so if you see a spelling mistake please make a pull request to the **staging branch** with a clear git comment just targeting those, I would like to separate the two things. I mean improvements to format and typos from logic and improvements to the compiler it self.

Llewellyn commented

2017-12-14 11:17:06 +00:00

Just that you know, since JCB is only in English at this time I did not make that a priority, but we are working on a German, and Afrikaans translation then it will become very important and I will fix the issue.

Llewellyn commented

2017-12-14 11:33:20 +00:00

Just a side note, in the last pull request I again found many areas changed (formating) that had nothing todo with the issue at hand, can you please insure that your editor does not change the formating of the files. I do not what to go down the road of constant change to format between us, I am willing to also make changes on my side to try and insure we get to a stable point. Here is a screen shot of my IDE settings:

Let me know what you would like to change and lets find a common ground, @ro-ot and I have already done this, so any change to my formatting will also effect his.

Just a side note, in the last pull request I again found many areas changed (formating) that had nothing todo with the issue at hand, can you please insure that your editor does not change the formating of the files. I do not what to go down the road of constant change to format between us, I am willing to also make changes on my side to try and insure we get to a stable point. Here is a screen shot of my IDE settings: ![image](https://user-images.githubusercontent.com/5607939/33989842-a5045cd6-e0d1-11e7-89f1-8b0be63f987d.png) ![image](https://user-images.githubusercontent.com/5607939/33989860-b5130028-e0d1-11e7-93c8-642a5fbd9b6f.png) ![image](https://user-images.githubusercontent.com/5607939/33990261-fa8e6e20-e0d2-11e7-805b-fae04cc891cf.png) Let me know what you would like to change and lets find a common ground, @ro-ot and I have already done this, so any change to my formatting will also effect his.

stutteringp0et commented

2017-12-14 16:02:31 +00:00

(Migrated from github.com)

This is what I try to follow, because I spend a lot of time in the Joomla repository

https://developer.joomla.org/coding-standards/php-code.html

This is what I try to follow, because I spend a lot of time in the Joomla repository https://developer.joomla.org/coding-standards/php-code.html

Llewellyn commented

2017-12-14 16:14:28 +00:00

Okay I see they use 4 spaces

Indenting

Tabs are used for indenting code (not spaces as required by the PEAR standard). Source code editors or Integrated Development Environments (IDE’s) such as Eclipse must have the tab-stops for indenting measuring four (4) spaces in length.

I will update the compiler to also use 4 spaces for tabs, I thought we were on par with Joomla, sorry about that.

I have tried to hold to their standard as well... was out on the tabs... will again give it a closer look.

Okay I see they use 4 spaces ## Indenting Tabs are used for indenting code (not spaces as required by the PEAR standard). Source code editors or Integrated Development Environments (IDE’s) such as Eclipse must have the tab-stops for indenting measuring four (4) spaces in length. I will update the compiler to also use 4 spaces for tabs, I thought we were on par with Joomla, sorry about that. I have tried to hold to their standard as well... was out on the tabs... will again give it a closer look.

stutteringp0et commented

2017-12-14 17:16:29 +00:00

(Migrated from github.com)

They've changed it a couple of times. When a new project lead is assigned - they adjust to their preference.

Things are a little weird in there for the J4 development. It's a minefield of toes - I've stepped on a few.

They've changed it a couple of times. When a new project lead is assigned - they adjust to their preference. Things are a little weird in there for the J4 development. It's a minefield of toes - I've stepped on a few.

stutteringp0et commented

2017-12-14 17:57:52 +00:00

(Migrated from github.com)

They have other things they obsess about. blank lines must have no length (no tabs or spaces). they obsess over spaces trailing code. Their automation is a real pain to deal with. I issued a pull request for a HTTP headers standards compliance update - and it took a ton of edits to get the code to pass the automation.

Llewellyn commented

2017-12-15 22:23:23 +00:00

I am trying to update the code all over to the Joomla standard, you will see there is a pull-request open on that. Your feedback is welcome.

JText - other than the "_" method #198

Indenting