Look over the translation-files

[DomeDan]

Continue from viewtopic.php?f=3&t=26708

I would like to overlook the translation files, because some translations break vicidial functionality.

Its the one-word translations that is the problem, here's some of the translations im talking about:

BORDER
VALUE=SUBMIT
TYPE=SUBMIT
MAXLENGTH
English
Spanish
French
German
Italian
Title
SUBMIT
Incoming
Calling
Called
Campaign
Status
Inserted
HELP
Password
VERSION
BUILD
Server
PARK
NUMBER
CALLERID
PICKUP
CONFERENCE
Refresh
ORDER
Extensions
Conferences
Conference
Recording
Record
Welcome
VOICEMAIL
Resume
Faster
Slower
Initializing
Invalid
Username
First
Last
Address
City
State
PostCode
Province
DialCode
Show
Email
Comments
REFRESH
ADDRESS3
Phone
January
Frebruary
March
April
May
June
July
August
September
October
November
December
VOLUME
Undefined
CONSULTATIVE

Just imagine how many variables, functions and id's containing the word: Status

I wrote a command to check out where words will be translated:
cat translations/se_language.txt | grep -v 'agc|' | cut -d'|' -f1 | grep -v '^#' | grep -v '^*' | grep -v ' ' | sed 's/\"/\\\"/g' | xargs -I {} grep --color -n -e '{}' www/agc/*.php
and there you can easily see that many translations interfere with functions and variables.

some of the words is written like ">LOGOUT" and that's what should be done to more of them, but some can just be removed viewtopic.php?f=3&t=26708#p93906

I volunteer to do this work but I first need to ask matt or any other developer,
what are some of the translations really for? especially the first onces:
BORDER
VALUE=SUBMIT
TYPE=SUBMIT
MAXLENGTH

[Framercy]

Maybe I can help here because I saw what these terms are doing while translating the stuff...

BORDER
VALUE=SUBMIT
TYPE=SUBMIT
MAXLENGTH

These are keywords of some html elements. These terms could be safely removed from translation files because they have not to be translated. Otherwise functionality will break in all cases here.

Let me give you an example:

VALUE=SUBMIT is for all the submit bottons in the script - totally catastrophic if one of this values would be changed or translated...

Best regards
Fram

[DomeDan]

Yeah I know where they will translate and I don't see any reason to translate them.

But my question is why, why were they added to the translation-files in the first place?
gonna check if its something I've missed that the developer thought of.

[Framercy]

I can't think of any reason other than a mistake...

But lets go a step back Value=SUBMIT is not for the Type than for the Value that these buttons become - and therefore the only thing here that has to be translated - sorry

Best regards
Fram

[mflorell]

I know they were all added for a reason at some point. If everything works without them present then feel free to remove them.

Thank you for working on this, the translations usually take several days to do when we do a full release, so any help to make that process work better is much appreciated.

[DomeDan]

Now I've made some changes to build_translation_www_files.pl and se_language.txt to be able to use regular expression on variables and similar and also print the translated line.
(still the same layout on se_language.txt)

here is the script in action: (and yeah, this is exactly how the output looks at the moment)

"Preview the Lead then (.*) DIAL LEAD(.*) or (.*)SKIP LEAD" "Förhandsgranska Lead och $1 RING LEAD$2 eller $3SKIPPA LEAD"
vicidial.php: var man_status = "Förhandsgranska Lead och <a href=\"#\" onclick=\"ManualDialOnly('" + manual_dial_only_type_flag + "')\"><font class=\"preview_text\"> RING LEAD</font></a> eller <a href=\"#\" onclick=\"ManualDialSkip()\"><font class=\"preview_text\">SKIPPA LEAD</font></a>";

and here is a comparison of the original and the translated row:

var man_status = "Preview the Lead then <a href=\"#\" onclick=\"ManualDialOnly('" + manual_dial_only_type_flag + "')\"><font class=\"preview_text\"> DIAL LEAD</font></a> or <a href=\"#\" onclick=\"ManualDialSkip()\"><font class=\"preview_text\">SKIP LEAD</font></a>";
var man_status = "Förhandsgranska Lead och <a href=\"#\" onclick=\"ManualDialOnly('" + manual_dial_only_type_flag + "')\"><font class=\"preview_text\"> RING LEAD</font></a> eller <a href=\"#\" onclick=\"ManualDialSkip()\"><font class=\"preview_text\">SKIPPA LEAD</font></a>";


tried using (\$\w) when I only want to match a variable but it didnt work.. but (.*) works just fine so far.

Still got a lot more translations and tweaks to do, and then testing and more tweaking

the translation function is based on this on "repl" http://stackoverflow.com/questions/3926 ... 649#392649
but with a small change to return false if there was nothing to translate

Matt: what's your thought of this solution? something i should think about when I continue working on this?

[mflorell]

As long as you can document it thoroughly and it will work consistently then it should be OK with me.

[DomeDan]

uploaded a version of build_translation_www_files.pl and se_language.txt if someone wants to take a look and test it http://www.vicidial.org/VICIDIALmantis/view.php?id=663
it breaks the "english->english" translation so "--without-en" is enabled

Matt: What do you think about changing the "english->english" translation to simple like sed replace "INTERNATIONALIZATION-LINKS-PLACEHOLDER"-stuff?

[dspaan]

Hey DomeDan,

I made a post here about making translations in general. viewtopic.php?f=3&t=27615&p=97607&sid=7477535c7e6cbd241afa323cb1e0740c#p97607

Can you maybe mock up a step by step guide on how to make a translation? That would allow people to contribute and update the existing translations and add new ones. I want to make a Dutch translation for instance. I have no clue where to start, i read about the pl script for generating the files but where are the source files that i have to actually edit? And how about the buttons? And will this work for the latest SVN features?

[DomeDan]

I will think about a step-by-step guide and I might write something in the future when I'm done with this project.

Regarding English agc page, it seams that the script didn't break it after all! it was just me who thought it would break it because I thought it worked differently then it did.

So now I've uploaded a new version and even added a function to print out the unused translations!
Matt or anyone else in the Vicidial team, can you try it out and tell me what you think? http://www.vicidial.org/VICIDIALmantis/view.php?id=663
only worked on the Swedish translation so far, but I will try to write some script to create other translation-files (but they still need some manual editing afterwards)

One thought I had was that maybe some code should be added to prevent that files can be missing in agc_* if they are not specified under ***FILES*** as happen to dspaan here: http://www.vicidial.org/VICIDIALforum/v ... 607#p97677

[DomeDan]

Wrote a script to update other languages translation files (so its less manual editing and a bit easier view)
If there is any interest in this method to translate the files then I can of-course do as much manual editing in the translation files I can to create complete files for every language.

Have also been using the translated agc_se and the english agc_en, and its working fine for the testing I've done and have been using it on the agent-computers a week now.

Can I get some comments from the developers on this? so I'm not doing this work in vain

[DomeDan]

bump, no comments in almost 2 weeks

[dspaan]

Let me bump this for you

[DomeDan]

Thank you

[DomeDan]

Saw this in an other thread viewtopic.php?f=3&t=8487&start=40#p103340

We've been focusing on security and future compatibility issues with the web interfaces lately, and we should be done with those soon.

After those are done, we have already been approached by a company that has implemented a dynamic text lookup process in the agent interface. This company uses MySQL to store the phrases, which given Vicidial's construction, would probably be the way we would like to go instead of sticking with static text files. This would allow editing of phrases in a web interface, making for a much more easy-to-evolve translation process. We have even thought of adding easy export and import processes which would allow for easy sharing of translations on the vicidial.org website in some way.

So, in closing, it is something we are thinking about. We are planning on working on this after we have finished with the security and future compatibility changes we have been working on for the last several months. It will probably be a MySQL-based approach to storing the phrases that we end up using . And, we will probably start with only the agent interface using this method to start.

Sounds nice! so I consider this project closed, but its a fallback if the mysql method wont work.

[williamconley]

mysql not work? them's fightin' words. LOL

mysql could solve ANY problem. Except we're in MariaDB these days ... so ... I'm confused. But it will work even if the sql flavor is murky.

[DomeDan]

ah yeah, I'll just call it database stored translations then

one thing I come to think of that is negative with database stored translation is that the code will get more messy (I guess),
but there is still a lot of positive reasons with that method!

[williamconley]

It doesn't need to get messy. In fact, since all plain text will be replaced with "codes" it could get cleaner depending on the codes.

Which looks cleaner? A bunch of lines with text on them, or a bunch of lines with uniform-looking codes where they are all the same length? Could definitely be set up that way.

And a proper design will merely add a "create" method to grab all the page text as Constants during the first few lines. So all the text codes will just be able to be typed plain after they are loaded. Could work quite well.

Instead of:

echo "Admin User Group:"

echo ADMIN_USER_GROUP.":"

not a lot of difference, really. At least for Field Names.

[FredrikL]

Hi,

is there a swedish translation for GoAutodial 3 yet?
trying to find some updated post, but this seems to be the most recent updated.

Would appreciate if someone has a guide how to get special characters like åäö to work. The leads are loaded from .csv UTF-8 with the right characters in the file..

Fredrik

[DomeDan]

Hello Fredrik!

There is a setting called "Use Non-Latin", if you set the to 1 then special characters wont be stripped from anything,
but you will be vulnerable to any basically any attack so I suggest you set it to 0

This is how I did it:
viewtopic.php?f=5&t=26684
But I have not used the build in lead loader that much so I'm not sure this is the issue