Simple develop

[Valc]

Hi, :)
This is a more simple and less complex to use way than allow handle changes in language files from Github.

The main config is handled from Com_localise >> "Options" tab.

To make it run is required set "Allow develop" to "Yes"

Going to "Localise" >> "Translations" view and after choose a client and tag the program will start getting the files from Github for that selected client (try getting all clients files at same time normally crash).

One time is ready we can see what files have changes at Github.

After edit here is the output for new keys

And here for text changes:

Editing the "en-GB" tag we can handle text changes saving the reference in develop there (and no more notice about it):

Note that the new keys in develop, one time the language file is saved, will not be showed as new again.

Also note that i am using new images from Github and maybe is required choose another ones.
It is the draft.

Regards, Valc

[infograf768]

Will test asap!

[infograf768]

Great work and much easier than previous proposed solution! 👍

Important: it is necessary to use such a patched com_localise on an instance of Joomla corresponding to the last stable release. (I first tested on staging and, evidently, did not get any changed strings...)

=> Would be great if we had a similar way of knowing text changes as you do in TTM diff tool by choosing in Options with which stable source version we should compare. If possible, then we can use it on master/staging and test results of changes almost on the fly.

Default target github version should be master rather than staging.

Improvements to make it easier:

1. Filtering by "text changes" when editing an ini (btw I would rather use "Modified values" instead of text changes)
2. Displaying a supplementary way to the tooltip in the translations manager to know if there are "changed" strings values in the files. Another icon maybe in the Translated column, below the percent?

Important!
Is the "Github branch" parameter field in Options=>tab "Develop details" limited to en-GB in core?
In that case (which is fine imho) we could rather use the term "en-GB development reference language" instead of "develop".
Also, and this is important, as it will work ONLY if the "Reference language" is set to en-GB in the Options=>Global Configuration, we have to state this in a way or another in both tabs in an obvious way (I mean not only in a tooltip).

[Valc]

Hi, @infograf768:

Thanks for your feedback and comments.

All the suggestions over this new draft can to be done without problem.

The fast to solve:

• Change "staging" to "master", or create a fixed list of available branches to choose.
• Filtering by text changes.
• Use "Modified values" instead of "Text changes"
• Add an icon for "Modified values"
• Use the term "en-GB development reference language" due the stuff in this way is limited to en-GB in core.
• Send a warning when "Reference tag" is distinct to "en-GB" (from getGithubfiles function now is returning "false" when the case is detected, but without send the notice), and maybe i forgot add the same control from the models or views files that i have modified.

The other suggestions have more task and maybe will be limited:
The diff between TTM Diff tool is that it can get packages from Github or not, and in the actual case we are limited to get language files that are stored at Github with him SHA id and related tag to mount the list of "Knowed Joomla releases", so here the list will be shortest.

But i think is good enough with the available ones and a great idea than will allow us to know the diff from those to the new ones.

Is more time and code to do it, but not more complex.

So, i will start with the fast to do and then i will follow with the other one.

Regards, Valc

[infograf768]

Thanks.

Concerning 2. took time to find the github icon as it is a binary and I could not get it by .diff
I have used the "icon-16-notice-note" instead of the github one as I did not like it :)
Changed the translations view accordingly:
<br /><span class="icon-16-notice-note hasTooltip" title="<?php echo JText::_('COM_LOCALISE_TOOLTIP_GITHUB'); ?>"></span>

added the css in localise.css:

span.icon-16-notice-note {
    background: url("../../../media/com_localise/images/icon-16-notice-note.png");
    background-repeat: no-repeat;
    height: 16px !important;
    vertical-align: text-top;
    width: 16px !important;
}

and copied the file in the localise images folder
I get:

[Valc]

I also like more your chooses image :D

Now we have done the fast to do:

Filtering by text changes:

Sending message when reference language is distinct to en-GB

And adding more basic info about how is running

Your changes that now also are showing by tooltip the amount of present new strings or text changes for fast review.

You have write access to my repository, so feel you free to add improvement or details when required.

Regards, Valc.

[infograf768]

I corrected some strings.
Let's finish up before introducing JPlural.

[Valc]

Thanks JM, your changes are also updated.

Now is ready the first part, but not finished the task (i have only the weekend to make it).

This means that seems it is working fine with the "Translations" and "Translation" views (get other Joomla releases as reference, display the news against last in develop, edit and save files...)

But is pending to revise the "Packages" or "Languages" views, if affected by the new features code.

From Localise >> Options >> Global configuration tab is added the "Customised en-GB files" field than allow choose from the list the Joomla version to use. The default set is the installed one.

The list is not complete, but can to be updated from 'getCustomisedtarget' function at localise helper and we can add any other Jooomla release stored at Github.

Need we add 2.5.x series?

One time we are using a customised reference, from 'en-GB' tag we can know what release is used.

Note that now if we are using the customised option, the alternative global folders in "media" path only have that set of customised core files to display (and other ones coming from non core extensions maybe installed within normal global paths are not added in "Translations" view).

The language files installed within "local" or extension folders are not affected by this one and also will be displayed, if present.

I think is good leave it working in this way for users than have translated an older Joomla version and they only wanna know the news in core to leave equal the xx-XX with the last one in reference.

But i also can force it to add the non core files presents in main reference to the customised reference if you like it more.

Note that now the feature 'customised reference' also can works with 'allow develop' configured to 'No'. So, in this case i don't know how many useful can to be it. If not useful, we can force to use 'Allow develop' configured to 'Yes' when 'Customised reference' is distinct to 'Local instance'. Now is allowed also with 'No' due i am not sure about if it is useful or not.

And also note that the program is storing customised references by each Joomla release to choose from the list, due use only one path for all them make it run very slow for each time than we make a change in 'Customised en-GB files' list.

The pending to do as second part the next weekend:

• Revise "Download package" or "fields" files when they are mounting the list of files (or any other file that is calling 'LOCALISEPATH').
• Revise client installation.
• Add Jtext.
• Details.

Please, let me know any stuff before i start second part :)

Regards, Valc.

[infograf768]

thanks!
not sure I understand all you wrote.
will test asap

[Valc]

Yep, i have modified a bit the previous comment.

Regards, Valc.

[infograf768]

Sorry, Valc. I can't get this to work.

I installed it this time on a test site updated to staging/master.
I installed a fr-FR 3.4.1 pack.

What shall I do to get the "Modified values"?

[Valc]

To get the modified values 'Allow develop' always should be configured to 'Yes'. This field always is pointing to the newest language files versions.

From 'Customised en-GB files' You can use the installed language files by default or choose other Joomla versions. This field always is pointing to older or equal language files versions than in 'staging' or 'master' trunks.

On an master installation If you choose at 'Customised en-GB files' the Joomla 3.4.1 version when 'Allow develop' is configured to 'Yes' and 'Joomla Github branch' is 'master' you can know the diff from 3.4.1 vs the last in master trunk.

So 'Customised en-GB files' is working as the files that we have installed and 'Joomla Github branch' as the newest language files version against what to do the test.

If source version and target version is equal there is no diff to show.

[infograf768]

Except for the version vs which the comparison is done, it works.
I.e. I do not get

but

Looks like your screenshots compare both en-GB instances and not the language we work on compared with an en-GB instance.
In that case, I get

And there is no filter to get the modified values or untranslated (new) strings when editing such an en-GB file.

I suggest to aim at the following action:
When we compare and solve a Modified value (by changing the value or NOT, as it is often only an en-GB grammar stuff...), we should have a way to mark that string as translated (or the file complete again) in order to not have to edit again all en-GB modified values in the en-GB files to get rid of the icon. That step is really a heavy load.
Also, we should have a new filter in the Translations view to display only files with untranslated OR/AND modified strings in the Manager.

[Valc]

"Except for the version vs which the comparison is done, it works."
It is odd, i think is not required do a Localise >> Packages >> "Purge database" action to start showing the customised en-GB path, but maybe you can test if with purge database it is showed when en-GB tag is showed.

If not, no problem due i have founded another improved way to make it run, and your commented issue will be not possible to happens with the new mode to make it run.

With the new mode, this than now is showed at the en-GB path can to be done with more detailed info by accordion close to "Icons legend" within translations view, with any choosed tag.

Also and after revise, i think is better move the field "Customised en-GB files" to the tab "en-GB development reference language" due "Customised en-GB files" needs be working with "Use development reference language" as "Yes" to have sense.

Maybe the tab, due is handling more than newest files from Github, can to be called other stuff (en-GB reference versions or Customised en-GB options or en-GB Reference and develop)

Also change "Customised en-GB files" to "en-GB - Source reference" (or source version)
and "en-GB development reference language" to "en-GB - Target reference" (or target version)

And explain there by "Desc" what means each stuff.

"Looks like your screenshots compare both en-GB instances and not the language we work on compared with an en-GB instance."

I don't understand that at all.

To get the diff between en-GB files we need a source en-GB reference and a target en-GB reference, and one time we have the diff between both we can make notice what is required update over any other xx-XX language tag.

Before add the "customised en-GB files" field that "source" was always our installed en-GB language files and out target reference was the files at Github in master branch (or any other allowed to choose)

After add the "customised en-GB files" field that "source" now also can to be based on other Joomla releases to choose from a list.

The no possible is use 2 source references or 2 target references at same time.

"When we compare and solve a Modified value (by changing the value or NOT, as it is often only an en-GB grammar stuff...), we should have a way to mark that string as translated (or the file complete again) in order to not have to edit again all en-GB modified values in the en-GB files to get rid of the icon"

It is not a problem add a checkbox only for modified values, but the program can not know if it is an en-GB grammar case or not.

For that cases we can edit the en-GB file and insert the new text value to solve, but with a check box we need to do the same: edit the en-GB file >> select the checkboxes with grammar cases >> Save the en-GB file. So,do that at en-GB means "grammar case".

And this one will help, with checkboxes or not, to hide that ones for any other xx-XX language tag.

But when is time to hide the real text changes at xx-XX tags, each selected checkbox there means "revised" and each translation can have "revised" the text changes or not, so also will be required edit tag by tag >> choose cases >> and save. With or without checkboxes we need edit and save the affected files.

I really wanna mean that edit, choose modified values and save the language file are the required steps to configure and hide all "grammar cases" by en-GB tag or all "revised cases" for any xx-XX tag.

"Also, we should have a new filter in the Translations view to display only files with untranslated OR/AND modified strings in the Manager."
Yes, this one is easy to make.

Regards :)

[Valc]

I think than now the "complete" issue is solved. Please, test it.
Regards and sorry for the delay, i am really bussy.

[infograf768]

Thanks, I have to find a way to test without breaking the site where I create my packs. 😄

[infograf768]

This works well now. 😃
Looking if I can create the necessary new lang strings to replace some hard coded messages.
If yes, will commit to your branch before merging and releasing new version

[Valc]

Great!
Please, i need help with the language phrases of this file:
../component/admin/views/translations/tmpl/default_references.php
I have not added the constants there due seems more easy to make the correction in this way and one time is ready add all the required language constants.

I also need improve a bit a commit about 'mounting language files' (it will be done in a moment today).

Regards, Valc.

[infograf768]

Please do not touch anymore as it is pretty hard to follow what you have added or just updated vs master.

What do you mean by "mounting files"?

[Valc]

I have noticed an issue that make fails this pull if not solved, related with the way about how are readed and added the language lines coming from several paths (mounteds) to the file to save.

The stuff is that the file, before edit it has no errors, but after save it, if that issue is present, the file will be saved with errors and displaying the icon 'Translation file contains errors'.

This case was happening editing my 'es-ES.lib_joomla.ini' file without errors and getting errors after save it due the way about how is mounted the file before save it.

With the other way we was inserting errors at he content file and with the new code the issue is solved making notice it.

I think that this one happens due the BOM! issue or not Linux EOL present in one of the two files used to mount the final file to save (en-GB and xx-XX language files are normally used to mount the final xx-XX translated file).

Regards

[infograf768]

I am confused about the term "Mount".
Shall we rather use the term "Parsing" ?

[infograf768]

Hmm
I think we just should not use the term "mount", just say that the line could not be added.
I never had the issue so I have no idea how to reproduce it.
working now on strings.

[Valc]

Yes, please, replace the word "mount" by other one more easy to understand or change the message to other explaining that "The next line can't be added due parsing errors: "
Regards

[infograf768]

I guess we can now merge this.

[Valc]

Great!
At the end, this one called "Simple develop" when we start... have been included more things than I could imagine ;)

Thanks for your suggestions and help :)

Regard, Valc.

[infograf768]

@Valc
Can you look again at
#276

[Valc]

@Valc
Can you look again at
#276

Yes, revised and agree with the new way you have used to handle the issue.

Other stuff: reading another pull talking about tables with utf8mb4 support, make me notice a task pending to do at this simple develop pull:

Add the pending files type 'update sql' for those persons that are updating the com_localise from a not included versions to update, due without add the new table '#__localise_revised_values' they will not be able to use the check boxes feature.

This is the last file added by me:
component/admin/sql/updates/mysql/4.0.12-dev.sql

The pending is add a file for each release after the 4.0.12-dev version.

Now that this one is merged, how is handled add the pending sql files related with updates?

Regards

[infograf768]

@Valc
Do we need a 4.0.xx-dev.sql for each version released?

If yes, then just make a PR adding these for 4.0.13, 4.0.14 and 4.0.15 as next release will be 4.0.15-dev

[Valc]

Done at #288