Joomla 1.5 Language Files Manager Component

[igevans]

1. the View Files icon not working. Clicking on the figure in the column works.

Thanks - fixed this.

2. When language debugging is on in Global Config, xml column icons  and Files number show the ??  ?? as if these strings had to be translated.

Have added the XML phrase definition to the INI files.
The files number, and other strings, got the ?? ?? in debug mode because they were passed through the TranslationsView::tooltip() function.  I've changed this so that it is more configurable, as below.

Will wait for any more corrections/bugs before posting revised code to forge.  Hopefully getting this pretty near final by now.  Thanks for all your help.

igevans

Code: Select all

/**
* Lookup and return a tooltip, using JText
*
* The default behaviour when using JText is
* 1: if $caption is not set, set it to match $html
* 2: if $tip is not set, lookup a JText key in the format '$caption DESC' and use it ONLY IF DEFINED
*
* @param 	string 	The HTML over which the tooltip will appear
* @param 	string 	The tooltip
* @param 	string 	The tooltip caption
* @param 	string  A string including characters H T C to trigger JText of Html Tip Caption
* @param	boolean	Use Overlib instead of mootools
* @return 	string 	The HTML output
*/
function tooltip ( $html, $tip=null, $caption=null, $jtext = 'HTC', $overlib = false )
{
	// prepare JText config
	$jtext = ' ' . strtoupper($jtext);

	// 1: lookup an Automatic JText tip and caption
	// 2: lookup an Automatic JText caption
	// 3: lookup JText $tip and $caption
	if ($jtext) {
		if (is_null($tip)) {
			$caption_key = ($caption) ? $caption : $html;
			$tip_key = $caption_key . ' DESC';
			$caption = strpos($jtext,'C') ? JText::_($caption_key) : $caption_key;
			$tip = strpos($jtext,'T') ? JText::_($tip_key) : $tip_key;
			$tip = ($tip==$tip_key) ? '' : $tip;
		} else if (is_null($caption)) {
			$caption = strpos($jtext,'C') ? JText::_($html) : $html;
		} else {
			$caption = strpos($jtext,'C') ? JText::_($caption) : $caption;
			$tip = strpos($jtext,'T') ? JText::_($tip) : $tip;
		}
		// lookup JText $html
		$html = strpos($jtext,'H') ? JText::_($html) : $html;
	}

	// add the tooltip to the html
	if (($tip) || ($caption!=$html)) {
		// apply title to tip
		if (!$tip) {
			$tip = $caption;
			$caption = '';
		}
		// 1: overlib method (manually include overlib JS)
		// 2: class/mootools method
		if ($overlib) {
			global $mainframe;
			$url = $mainframe->isAdmin() ? $mainframe->getSiteURL() : JURI::base();
			if ( !$mainframe->get( 'loadOverlib' ) ) {
				$doc =& JFactory::getDocument();
				$doc->addScript($url.'includes/js/overlib_mini.js');
				$doc->addScript($url.'includes/js/overlib_hideform_mini.js');
				$mainframe->set( 'loadOverlib', true );
			}
			// build HTML
			$html = '<span onmouseover="return overlib(\'' . addslashes($tip) . '\',' . ( $caption ? 'CAPTION,\'' . addslashes($caption) . '\',' : '' ) . 'HAUTO,VAUTO);" onmouseout="return nd();">' . $html . '</span>';
		} else {
			JCommonHTML::loadOverlib();
			$html = '<span class="hasTip" title="' . ( $caption ? htmlspecialchars($caption) . '::' : '' ) . htmlspecialchars($tip) . '">' . $html . '</span>';
		}
	}
	// return
	return $html;
}

[ibnhafsun]

My suggestion: the default Components/Translation Manager view is "Any Client" (may be "all" would be easier to understand" and it makes hard to understand and get it (the first files are the installation files). It would be nice if the default view is "Site". But that´s my opinion as a simple user.

I guess you have thought about the contextual help too.

The "view files" button doesn´t work here:
PHP Version:  5.2.0
Web Server: Apache/2.2.3 (Win32) DAV/2 mod_ssl/2.2.3 OpenSSL/0.9.8d mod_autoindex_color PHP/5.2.0

[igevans]

Just uploaded latest version to forge, which fixes:
* View files button
* JText behaviour
* INI strings
* JMenuBar::configuration method rename in core on 10 Feb 2007

You will need the new version if you are up to date with nightly builds, it can be downloaded from Forge

I have also created a Joomla Extension - feel free to rate and review 

Ifan

My suggestion: the default Components/Translation Manager view is "Any Client" (may be "all" would be easier to understand" and it makes hard to understand and get it (the first files are the installation files).

You can change this by editing the "en-GB" language INI file.

[infograf768]

In SVN 6599, I get this error when accessing the component
Fatal error: Call to undefined method JCommonHTML::loadoverlib() in /Library/WebServer/Documents/joomla11new/administrator/components/com_fftranslation/view.php on line 113

[igevans]

There are a couple of bugs due to recent changes in the nightly builds:

10 Feb 2007 -
    renamed = JMenuBar::configuration() to JMenuBar::preferences()

#6599 -
    removed = JCommonHTML::loadOverlib()

zipfile attached with the necessary changes to view.php.  This includes a hack to check for JMenuBar::preferences(), so it should work with builds from the last few weeks.  I have also updated last night's zipfile on the forge.

FWIW renaming and deleting methods is very annoying - surely it would be better to leave the original methods with a $mainframe->enqueueMessage() saying that it is deprecated and is to be deleted in a few weeks, bouncing to the new method in the meantime.  Then things wouldn't break so dramatically (for me these errors break the whole application, because the JDatabase object tries to connect using ODBC@localhost with no password).

igevans

[infograf768]

Maybe worth waiting some more stabilization in core? 

[infograf768]

CSS/layout issue

See picture

[infograf768]

BTW: look here
http://forum.joomla.org/index.php?topic ... w#new 

[igevans]

Thanks JM,

CSS - I think I'll take as much as possible of the CSS out into a file, so that it can be configured by users.  I would like to put the CSS in the preferences as a textarea (if it's short enough) but at the moment JRegistryFormatINI breaks when there are quotes or newlines in any of the INI values.  I have an improved JRegistryFormatINI which handles quotes and newlines - any idea how I could get it added to or considered for the core/SVN?

ItemID refactoring - will take a look and use to tidy up links/routes

Ifan

[infograf768]

I am sending a message to devs concerning JRegistryFormatINI 

Css: that one could have a float right I guess and width auto to accommodate longer phrases.

The component (except for some core refactoring that would imply some changes), looks now real good now.
It is fully usable.

[vancanneyt]

was a bit to soon posting this, filezilla didn't overwrite view.php with the patch provided here, sorry guys
i'll test further

is the maker of the component happy with a translation?

grts

[Roman Blanty]

As I had some 1.5 translation done and in process of translation I found it convenient to empty untranslated strings I needed a bit of code altering for my purposes (to show and count empty strings as untranslated). Thanks to Ifan's prompt response pointing me to right places in code I managed to do it. For those who would like to do the same:

in com_fftranslation/helper.php (line 128 nn)

Code: Select all

        } else if ($v!='') {
            if($v!=$ref_strings[$k]) {
            $file['changed']++;
            }
        } ...

in com_fftranslation/views/edit.php (line 68 nn)

Code: Select all

        } else if ($v['edit'] == '') {
            $row->ref = $v['ref'];
            $row->refshow = htmlspecialchars($v['ref']);
            $row->cb = '';
            $row->style = ';border-left:solid red 2px;padding-left:2px';
        } ...

I still find some inconveniences in the way component handles counting translated vs untranslated.

Problem with counting 'unchanged' strings: In many cases of languages using Latin alphabet some strings stay the same which doesn't mean they are untranslated.

I don't understand how it chooses that file translation is complete. Maybe something is wrong at my side but it automatically turns files that have 84% (176/209) to complete. I think it counts unchanged strings as translated after all.

Said all this, maybe it would be better to clear all fields which are the same as in reference files and count only empty ones as untranslated. These strings which will stay the same as in reference file are usually one word strings so it is easy to copy them in process of translation. With this method we can get exact number of translated strings and no confusion. It would also enable beter groupworking if component 's multireplace tool would skip replacing combos with empty definitions. It should then keep in memory all possible replacements for open files and apply them if definitions are left empty.
What do You think?

Other minor things:
It seems that select all doesn't work in files view.
I can't save preferences in Moz 1.7.13 (Gecko/20060414). I worked it out by altering default values in editor.

It also would be great to be able to decide if 'same KEY=String combos' should be replaced in other files when saving current document, not globally.

SAME_KEY=Same string combos which could be translated in many files at once are mostly repeated in Front End against Administrator, does the component handle it? (by now in case it doesn't I copied administrator files (reference and translation)  into site folder with altered names)

[infograf768]

Said all this, maybe it would be better to clear all fields which are the same as in reference files and count only empty ones as untranslated. These strings which will stay the same as in reference file are usually one word strings so it is easy to copy them in process of translation. With this method we can get exact number of translated strings and no confusion. It would also enable beter groupworking if component 's multireplace tool would skip replacing combos with empty definitions. It should then keep in memory all possible replacements for open files and apply them if definitions are left empty.
What do You think?

I see the clear field feature rather implemented when creating new language or new ini file.
As most of us are already working on partly translated files, the usage of "Mark this Translation File as complete" could do the trick.

An improvement IMO (which would replace the "Mark this translation as complete"), if feasible, would be to "Mark this string as translated" on a string per string basis when same as reference file (tick box), which would take off the red bar after Applying or Saving and not counting it in the number of strings remaining to translate.

[Roman Blanty]

I see the clear field feature rather implemented when creating new language or new ini file.
As most of us are already working on partly translated files, the usage of "Mark this Translation File as complete" could do the trick.

Let's not forget that there will be a lot of 3PD components to translate later on. Other thing is that you are referring to a part of more complex concept which if implemented wisely would solve second problem you a writting about without creating additional files or database entries.
As for partially translated files: idea is to clear only these definitions which are the same in reference file, so it wouldn't really impair work done. It would add some work, I agree, but IMHO not much for the price. It could be even less if we could have a button which if pressed would copy reference definition to translation definition (lets say small button betwen every two definitions).

An improvement IMO (which would replace the "Mark this translation as complete"), if feasible, would be to "Mark this string as translated" on a string per string basis when same as reference file (tick box), which would take off the red bar after Applying or Saving and not counting it in the number of strings remaining to translate.

I can't imagine implementing this functionality without additional file, or db table or using comments in INI files and all three possibilities don't look good for me.

[infograf768]

@Roman

This is why I wrote "if feasible"    (me non-coder...)

[Roman Blanty]

I'm not a coder myself that's why I wrote 'I can't imagine"

Just an idea for later: a module tracking progress of translations would be really nice gadget

[igevans]

Hello All,

Thanks for all the comments and ideas.

Blank Strings vs. Retaining Reference String -

As it stands, J!1.5 only imports the selected language file, then when you call JText::_('token') it looks for a value for TOKEN.  If you set your translation file to blank strings for all the untranslated strings, all these will be returned to the user interface as blank strings, because J! thinks that this is the definition.  This makes it very hard to test as the translation is in progress.  I would argue that best practice (and what the component does) is to initialise every token value to the reference language value, then let you change it.  You might in fact want a TOKEN to be a blank string in some case, although I can't think of any.  Might add as a preferences option, and will do the same for a 'copy reference string' button.

Untranslated count -

TranslationsHelper::getINIstatus() compares two INI files and returns a number of counts:
  changed = strings that differ
  unchanged = strings that don't differ
  extra = tokens that are not present in the reference file
  missing = tokens that are not present in the translation file
  strings = the number of tokens in the translation file
  refstrings = the number of tokens in the reference file
Then it works out the status using these counts.  Currently it sets status to complete if (strings=changed), but I will improve this to take account of missing and extra strings.  If the 'Mark as complete' checkbox has been ticked, the INI file header stores a 'last unchanged' count, and the status will be set to complete if (last unchanged=unchanged).  I've chosen to do ot this way so that if there are changes to the reference file (by someone else) the 'mark as complete' will be broken - otherwise you would not know about changes to the ref file.  The file listing always shows the actual counts in a tooltip.

Select All - fixed this bug

Preferences - I had this problem about a week ago.  The Preferences functionality is all handled by the J!1.5 core, and mine works now, so I assume a temporary problem.

Component translations - I have already received a hungarian translation, and will be happy to package any others, post to this forum or my email address.

Global replace, partial and group translations etc are something fairly major, but I agree that file versioning, even token versioning would be a good enhancement, but that would really need database interaction, and for the time being I'm trying to keep the component as simple as possible.  I need to have a think about it (and find the time, of course).

Ifan

[vancanneyt]

Here is the dutch translation of the component, fully translated into the Dutch Language.

[shultman]

This component looks really promising!

Got an error when saving a new file without making any changes in it, see picture:

I also noticed that there is no sv-SE.com_fftranslation.ini in the sv_SE directory, instead there are two other files there;
chk.sv-SE.com_fftranslation.ini and xx.sv-SE.com_fftranslation.ini

[igevans]

This component looks really promising!

Got an error when saving a new file without making any changes in it, see picture:

I also noticed that there is no sv-SE.com_fftranslation.ini in the sv_SE directory, instead there are two other files there;
chk.sv-SE.com_fftranslation.ini and xx.sv-SE.com_fftranslation.ini

chk.sv-SE.com_fftranslation.ini = this is a temporary file which "checks out" the translation file that you are working on.  It contains your user ID and a timestamp (user ID so that you cannot checkout yourself, timestamp so that files are automatically checked in after a while).  Can you verify user rights on the directory, since it appears that the file has been created but cannot be deleted.

xx.sv-SE.com_fftranslation.ini = this is the actual translation file, which has been renamed so that it is "unpublished".  Because it has been renamed, Joomla!1.5 core will not recognise it.  When you "publish" the file, it will be renamed to lose the "xx." prefix.

Here is the dutch translation of the component, fully translated into the Dutch Language.

Thanks, will add to the zip.

Ifan

[shultman]

chk.sv-SE.com_fftranslation.ini = this is a temporary file which "checks out" the translation file that you are working on.  It contains your user ID and a timestamp (user ID so that you cannot checkout yourself, timestamp so that files are automatically checked in after a while).  Can you verify user rights on the directory, since it appears that the file has been created but cannot be deleted.

xx.sv-SE.com_fftranslation.ini = this is the actual translation file, which has been renamed so that it is "unpublished".  Because it has been renamed, Joomla!1.5 core will not recognise it.  When you "publish" the file, it will be renamed to lose the "xx." prefix.

Thanks for the explanation.

Directory rights is set to 755 and file rights to 644.

[igevans]

Sorry, not your fault.  This was a (non-fatal) bug - fixed and will be posted to forge sometime soon.

Ifan

chk.sv-SE.com_fftranslation.ini = this is a temporary file which "checks out" the translation file that you are working on.  It contains your user ID and a timestamp (user ID so that you cannot checkout yourself, timestamp so that files are automatically checked in after a while).  Can you verify user rights on the directory, since it appears that the file has been created but cannot be deleted.

xx.sv-SE.com_fftranslation.ini = this is the actual translation file, which has been renamed so that it is "unpublished".  Because it has been renamed, Joomla!1.5 core will not recognise it.  When you "publish" the file, it will be renamed to lose the "xx." prefix.

Thanks for the explanation.

Directory rights is set to 755 and file rights to 644.

[Roman Blanty]

I dream about a bot which shows tooltip indicating which file language definition comes from and definition key... (some things are just to hard to find)

After 37 hours of constant work I've just finished translating all definitions, so my dreams may be twisted

I wouldn't accomplish this without Ifan's component. BIG thanks goes to you Ifan!

[ivo.apostolov]

First of all, the component rocks, thanks for it Ifan.

I only miss one nice feature - PACKING - means exporting a language to installable .zip file


--------------------
P.S. Bulgarian Translation of the component is attached

[igevans]

I only miss one nice feature - PACKING - means exporting a language to installable .zip file
--------------------
P.S. Bulgarian Translation of the component is attached

Good idea, anyone got any pointers on the xml and zip structure for a language installation file?  Also maybe pointers/examples on joomla library functions for creating zipfiles?
Thanks for the bulgarian translation

I dream about a bot which shows tooltip indicating which file language definition comes from and definition key... (some things are just to hard to find)

Have a look here at a trial plugin I've posted which goes some way towards this.  Unfortunately needs a few minor changes in the core JLanguage class, so I'm hoping these might get included by someone from the dev team.
http://forum.joomla.org/index.php/topic,138162.0.html

Ifan

[Roman Blanty]

I'm on it...

You are too good and too fast to be true, Ifan!!!

[infograf768]

@Ifan

Sample of installation xml is here
http://dev.joomla.org/component/option, ... d,33/p,69/

Only difference with blog is that any xml may be utf-8 now.
Typical header

    English(GB)
    en-GB
    1.5.0
    2007-03-30
    Joomla! Project "Nameoflanguage" Translation Team
    info@siteoftranslator
    http://www.siteoftranslator
    (C) 2005 Open Source Matters. All rights reserved.
    http://www.gnu.org/copyleft/gpl.html GNU/GPL
   
   

[igevans]

@JM

Just finished a prototype packager - press one button and it zips up the whole set of language INI and XML files.  2 things:

1: There's a small bug in the joomla.filesystem.archive.zip file - change line 112 from

Code: Select all

return $this->_createZIPFile($contents, $ctrldir );

to

Code: Select all

return $this->_createZIPFile($contents, $ctrldir, $archive );

2: The zip file gives a 'ERRORNOTFINDJOOMLAXMLSETUPFILE' error.  I've attached the generated zipfile (site en-GB changed to xx-XX) so that you can have a look at the XML and/or archive structure.  Probably something obvious, but I'm not seeing it.

Ifan

[infograf768]

Sorry Ifan,

just was told some aspects have changed in this file.
I have asked for infos to devs and I'll let you know asap (or a dev will).
JM

[ivo.apostolov]

Ifan, I noticed something a bit not really user friendly.

If you are editing a file and click Save ot Cancel you go to the language list, it is more or less expected to be on the files list.