Is it possible that in the future, localizations could be with .po/.mo files? That way, translations would be easier to update. I thought that if we're going to switch to po/mo, it should be done as soon as possible. If GetSimple grows fast (and it IS growing fast), translations could be painful to edit & update in the future.

What’s the advantage with .po or .mo files? I can’t say I’ve ever used them.

For starters, it's easier to update those files. Developers update the .pot file (main translation file) and the translator opens his/her xx_XX.po file and loads the .pot file and the new entries show up immediately. The way we use, the updates would be WAY harder.

Plus, there are software like poEdit which can edit translation files so easily that we don't even need to use a mouse . It may seem unimportant but with my experience I can say that I can translate a .po file twice as fast as the .php file we work with currently.

And another thing, we can use functions in the core files. For example, if tr_TR.php does not have the line where $i18n['TOTAL_FILES'], there would be nothing in the place that phrase is used (upload.php). With po/mo stuff, you just write the function <?php __('total files'); ?> and if tr_TR.po does not have a "total files" entry, it shows "total files" so there's at least the English description in upload.php.

It's a little bit hard for me to explain it in English. The page below is a nice & small article about the advantages of this system:

http://www.gnu.org/software/trans-coord/...tages.html

And other articles:

http://www.google.com.tr/search?q=GNU+gettext

Only a small apology for resurrecting this old thread.

With the recent effort towards improving the range and quality of translations, I'd like to say that the current language files are a huge barrier to updating existing and procuring more i18n.

I acknowledge that converting GS to gettext would involve some investment, to say the least, but the benefits going forward would be enormous. Work on language files would be greatly reduced and less error prone. Being easier to work with, I suspect that more people would be able to contribute new files and improve existing ones.

well, we can look into this in the future, but the thing is when we first brought up the idea of i18n, i asked for suggestions - and this really wasn't talked about. I was (and still am) completely new to internationalization so i apologize for the way things are being done now. Not sure if we will ever change at this point, but I do see the limitations/problems with the current system.

I think you could put POEdit-Translation on the roadmap for further releases
as it is really great help

I do a lot of translations, for example for cmsmadesimple-modules or wordpress-theme "Suffusion" and it is really comfortable to work with that tools

I agree that until 10 minutes ago it was quite hard to translate the language files of GetSimple and plugins.

However, changing the format of the language files only because there are better tools to manage them, is only one way - but not nearly the best in this case:

• you would still have to download the language files from the web server (unless it's a local one)
  
• you need to know which program to use for translation,
  
• you need to start this program,
  
• you need to select the language file and maybe the source code for automatic scanning for codes,
  
• you need to upload the language file(s) to the web server
  
• etc.
  

A user, who doesn't know about file formats, available programs, etc., won't do it.

I think there is a better way - a plugin

• listing all plugins (and GetSimple) for selection by the user,
  
• scanning the selected plugin to see, if it conforms to the internationalization guidelines for GetSimple plugins,
  
• scanning the php files to find the codes used,
  
• displaying all available languages and their translation percentage
  
• allowing the user to translate from any language to any other language displaying the languages (and the codes) side-by-side, and
  
• saving the updated or new language files directly on the server,
  
• so that it can be tested immediately!
  
• And if you like it, you submit it to Extend with one mouse click! (future feature)
  

The Translate plugin is born!

Please download it, test it and give me your feedback.
(the only guide lines conforming plugins are probably I18N and I18N Search)

P.S. Nice sales pitch, isn't it ;-)

Nice pitch indeed. To avoid thread jacking, why not create a new thread in the plugins section for feedback?

@mvlcek,

great idea and nice plugin. A bit tricky to get source/target language at first, but it works - I already translated this plugin to Lithuanian . One issue - autogrow js fails to load if site is in subdirectory.

And I never liked the po/mo idea anyway.

Wow Mvlcek: i am very impressed. I wonder if we should turn this into a service @ get-simple.info instead of or in addition to a plugin?

Thank you for this...

Joshas Wrote:One issue - autogrow js fails to load if site is in subdirectory.

Should be corrected now.

Tested with latest r418 version - still doesn't work correctly - variable $SITEURL is empty. Tested in WampServer on Windows. Fixed it by replacing $SITERURL with .. (dir up). It works, but in translations with many lines autogrow causes a noticalbe slowdown. I'd suggest to replace autogrow with more basic solution.
Finally, there are several unclosed "</strong" tags in translate.php causing problems with layout.

@mvlcek: You have too much time on your hands! :-P

A great piece of work, congratulations. I had reservations about it being a plugin for the program it was to translate, but I can see some advantages there.

Joshas Wrote:Tested with latest r418 version - still doesn't work correctly - variable $SITEURL is empty. Tested in WampServer on Windows. Fixed it by replacing $SITERURL with .. (dir up). It works, but in translations with many lines autogrow causes a noticalbe slowdown. I'd suggest to replace autogrow with more basic solution.
Finally, there are several unclosed "</strong" tags in translate.php causing problems with layout.

Yes, $SITEURL is a front-end only variable - replaced it with ..
</strong> fixed.
Speed: Take a faster browser - just checked Chrome 10 - it only takes a quarter of the time to load the GetSimple translations in comparison to Firefox 3.6 ;-)

ccagle8 Wrote:Wow Mvlcek: i am very impressed. I wonder if we should turn this into a service @ get-simple.info instead of or in addition to a plugin?

Thank you for this...

Definitely. I mentioned some time ago that there should be a way to automatically add translation files to uploaded plugins

yojoe Wrote:

ccagle8 Wrote:Wow Mvlcek: i am very impressed. I wonder if we should turn this into a service @ get-simple.info instead of or in addition to a plugin?

Thank you for this...

Definitely. I mentioned some time ago that there should be a way to automatically add translation files to uploaded plugins

Yeah, and that may or may not happen - but the service I was walking about would be the ability to "create" a new language file for GetSimple right from our site. mvlcek would you mind if we used parts of this code to create a "language file creator" right on this site?

ccagle8 Wrote:Yeah, and that may or may not happen - but the service I was walking about would be the ability to "create" a new language file for GetSimple right from our site. mvlcek would you mind if we used parts of this code to create a "language file creator" right on this site?

Of course you can use the code, as its goal was and is to make translations easier.
But how do you want to do it?

Some ideas:

• For each plugin allow registered users to upload language files
  
• In the plugin info also list the languages included with the plugin
  
• The language files are available as separate downloads, not automatically included in the plugins
  
• Each language exists at most once (it has no owner like plugins), but a history of the uploaded files is kept
  
• Possibility to download all language files - zipped on-the-fly - mainly useful for developers, who want to include the languages in the plugin file
  
• Nice to have: The list of the language files should have the completeness percentages - where the codes that have to be translated are determined by the union of codes in the language files within the plugin and (maybe) the codes found by the source scan - these percentages must be calculated on submission of a language file and (for all language files) on submission of a new version of the plugin
  
• By having a completeness percentage it would not be important to specify a "for plugin version x" for the language files
  

For the language file creator you would have to unzip the plugin

• The codes are the union of all codes in all language files WITHIN the plugin - theoretically they should be the same ;-)
  
• The php files can also be parsed like in the plugin - and the found codes added - and those not found grayed out in the editor (it might not be correct, if the code contains $myvar='code'; i18n($myvar) )
  
• The language files OUTSIDE the plugin (those described above) are also displayed in the creator - it must be possible to see which are inside and which are outside
  
• you might want to provide a facility to save "work in progress" under the user's account - I think that's not necessary as long as the language files' history is available
  

Some related wishes for Extend and API:

• introduce and enforce the plugin name (= filename without extension) as a secondary unique key - it's the only information available from the plugins in GetSimple to identify a plugin. I don't think we have duplicate names yet - the earlier you do it the better
  
• new API functionality: plugin by name - same results as in current plugin by id - allows GetSimple to display current versions of plugins and suggest updates
  
• new API functionality: list available languages by plugin name - if available with completeness percentages
  
• new nice-to-have API functionality: search for plugins, returns list of results instead of a single result
  

P.S.: There is one thing you can't do with the language creator as opposed to the Translate plugin: test the translation immediately

I'm having some trouble getting this plugin to save anything. Testing on GS v3.0_r415, clean install (default, no other plugins installed except the Innovation support) on Debian 6 LAMP server; Firefox 3.5.16 on the client.

I can go to the plugin page, select 'GetSimple' to translate; source: 'en_US', target: 'new'; clicking 'Translate' brings up a list of codes and the en_US strings. I make my changes in the new column and click 'Save'. The view returns to the list of translation files, but nothing is saved in admin/lang/ (or anywhere). There is no on-screen acknowledgement; no GSDEBUG messages.

All file and directory permissions are good for Apache; no other problems with saving stuff.

Plugin versions: 0.2 and 0.2.1.

Also note that v0.2.1 times out (Unresponsive script, admin/template/js/jquery.min.js?v=1.5.1:16 warning) while loading the list of codes. Clicking 'Continue' in the FF dialogue box will allow the page to finish. This is a regression for me from v0.2.

Any troubleshooting suggestions, please?

A new version 0.2.2 of the Translate Plugin is available.

• Now the success and error messages are not only generated but also shown ;-)
  
• Thus undo is also available.
  
• German translation
  

@hameau: As you will see in the error message (hopefully), you need to create a writeable directory backups/translate, where backups for undo are stored.

Regarding the speed, I'm not 100% happy with the autogrow textareas, but it's the best way to display editable texts with varying lengths. Using Chrome 10 instead of Firefox 3.6 cut the time for displaying GetSimple's translations from 20 to 5 seconds (whole request) for me, on my faster computer it doesn't matter so much - both a few seconds.

But even if it's 20 seconds, it's not too much in comparison to how long you will spend on the page before submitting and how much time you save by not downloading the language file, opening it in a program, saving it and uploading it again.

CC: if you will embed mvlacek's plugin on the website, I'd like to ask for a possibility to paste current versions of translations to be parsed. Otherwise there will be a lot of copy->pasting. And I just ended finished translation for 408b.

mvlcek Wrote:As you will see in the error message (hopefully), you need to create a writeable directory backups/translate, where backups for undo are stored.

Regarding the speed, I'm not 100% happy with the autogrow textareas, but it's the best way to display editable texts with varying lengths. Using Chrome 10 instead of Firefox 3.6 cut the time for displaying GetSimple's translations from 20 to 5 seconds (whole request) for me, on my faster computer it doesn't matter so much - both a few seconds.

Translate v0.2.2: No change with the GS core language file. I click 'Save' and I just go back to the previous screen. No messages, no GSDEBUG errors. Same result with Chrome. It does work with the language file from i18n Base.

Incidentally, this is with Firefox and Chrome on a Debian desktop, though that should not be significant.

mvlcek Wrote:But even if it's 20 seconds, it's not too much in comparison to how long you will spend on the page before submitting and how much time you save by not downloading the language file, opening it in a program, saving it and uploading it again.

Are you trying to pick a fight? It has taken me longer to fail to get results from this plugin than I spent converting health-check.php to gettext and making it work, all in a text editor. ;-)

Just kidding, but there's a serious point, though it's just my opinion, of course. Translation should be done at a higher level and is not a frequent thing. The plugin only facilitates local user translation and cannot, of itself, improve the availability of languages, nor do anything about assuring the quality.

If the same process is to be provided as a service on getsimple.info, there is a whole load of new considerations, e.g., only one concurrent user per language; file locking to prevent concurrent file use; preventing malicious file locking by a user failing to release a session; version control; access control. (Not an exhaustive list.)

Mainly, it's re-inventing the wheel. For translation lookup files, use gettext. More precisely, use php-gettext, which overcomes most of the limitations of GNU gettext and the built-in php module. For an online translation facility, use Launchpad.

I really don't want to detract from your coding capability, which I think is enviable and I'll never reach your level. I just think this is duplicated effort.

hameau Wrote:Translate v0.2.2: No change with the GS core language file. I click 'Save' and I just go back to the previous screen. No messages, no GSDEBUG errors. Same result with Chrome. It does work with the language file from i18n Base.

Sorry, I didn't try saving with GetSimple files - I will try to find out the problem.

polyfragmented Wrote:Nice pitch indeed. To avoid thread jacking, why not create a new thread in the plugins section for feedback?

I agree. Can we take plugin troubleshooting to its own thread in Plugins?