Language file editor/translator

[eluser]mrkirkland[/eluser]
Hi Chaps,

I've just released a language file editor/translator front end. I wanted to create a friendly means for translators to go in and edit the language files, and so this is a web based front end to editing the language files, i.e. the

Code:

$lang['language_key'] = 'the language key text';

type strings.


More detail and download from this page

Cheers!

[eluser]Référencement Google[/eluser]
Very cool idea! I will test it.

[eluser]xwero[/eluser]
It is something i never got time to make although it's not that difficult to do. For my myCI script is am planning to do an config editor and a translator was on my list too but mine wasn't going to be a CI controller because the script is an installer first but maybe it should be added and lazy as i am i could steal this, that's what an installer script does

But i've got a few questions

Why is php5 and mb_string required? As far as i know the translator only gets/alters file content and creates files. I understand you need the mb_string functions for the exotic characters but if they are not installed you should be able to use the translator too.

I wonder why you need the php_syntax checking. The translator does the php format of the strings for you.

I'm not sure if it's in there but do you check for the same idiom in the system and application dir and join the files from both dirs on one page?

I think this is a great tool for people that need to maintain multi language sites.

[eluser]mrkirkland[/eluser]
I need the mb functions as I have multibyte characters in one of the languages. Chinese and Japanese will need this as they are all multibyte. I'm not sure about other languages, but I guess it would be smart to have multibyte handling as optional if not needed.

The php syntax checking is a double check to make sure your site doesn't get borked by a translator accidently typing something wrong. It does try and format the strings, but I figured there would be a possibility that something the translator typed could cause a php syntax error, which not be solved by the translator formating and would get written to the live site. The syntax check is a nice safety net.

At the moment this is geared towards the language files in your application folder, and leaves the system alone. I'm assuming that people keep their application specifc strings in their application folder, and the system language folder is for purely code igniter strings (i.e. dev error messages).

It could easily be used to edit the system files instead, if you just change the config file for:

Code:

$config['translator_langDir']

Glad to hear the generally positiive noises!

[eluser]ben_co[/eluser]
Great idea... I wanted to do the same kind of tool but you was faster than me :lol:

By the way, I have a small question. What about "concurrent accesses" ? Indeed, we all work with those text-file-based language files.

The problem I'm asking is when an admin write/modifies the target language-file... If a visitor must translate a specific word but the file is currently modified. How does it work ?

Ok, we could use the backup version if the new language file is "in use". But I think It only move the problem one step further. What if the backup file is also in use or simply doesn't exist ?

To resolve it, I was planning the make use of text and DB-based language files.

On one hand, when the admin want to update a specific language, we first update the DB and then modify the text file. On the other hand, if the visitor need a specific translation and the file isn't accessible (first access), it switch to DB.

What do you think about it ? Good or bad idea... ?

[eluser]xwero[/eluser]
I think the translator as it is, is more a developer tool then a front end tool so the multi user aspect is not something it should care about. There is no password protection and i don't think you don't want everyone to change your language files.

But it can be the base for a translation module with back ups and revisions.

[eluser]mrkirkland[/eluser]
I hadn't imagined a need for people to be working concurrently on the files and my feeling is this would be the exception rather than the rule. It's just meant to be a simple solution for editing the language files as used by the CI language class.

And as xwero points out, there's no password protection, but this would be pretty easy to add. I thought it best to allow people to integrate whatever authentication schemes they were already working with should it be required - it shouldn't really take more than a couple of extra lines of code if using a good authentication system. e.g.

Code:

$this->load->library('authentication_library');
$this->authentication_library->authenticate();

[eluser]ben_co[/eluser]
In fact, It isn't only a question of "working concurrently" on the files. It's rather a problem of "reading" the files.

For instance, If I update the file while someone wants display the website, how to be sure that he will dispose of a consistent version (not necessarily the last version but a complete version) ? I really don't know if there's no problem at this stage ?

[eluser]mrkirkland[/eluser]
Hi ben_co,

To answer your question, the user will visiting the site will get the latest saved version. So if you are editing the file, they won't see the version you are editing till you commit the changes. There is of course a brief period whilst the instant the file is being written when the web server may not be able to read it, which I think is what you are getting at. However this issue is not specific to the language file editor - it's the same any time you replace a file on your website whether it be via the command line, FTP or written by a php script etc.

Hope that's clear!

[eluser]moonbeetle[/eluser]
Trying to get CI 1.7.0 to work with this language file translator.
for some reason the edit screen stays blank. My language files are writable and since the translator tool can detect the language directories and language files (reffered to as modules) I don't think it's a path issue.

Can anyone confirm this tool is working for CI version 1.7.0?