Thread

Hi,

I couldn’t see turkish language files.

I am really impressed with EE but translating the whole EE will cost us a lot of time.

Is there any list showing the language files of the front end.

We can start with an english backend (ControlPanel).

So just translating only the front-end language files at the beginning will help us.

Thanks!

There isn’t a list that I know of specifying which words are ‘frontend’ and which are backend- though if you hit the ones for each module and ignore the ones for the cp, you’d come pretty close.

Have you had a chance to look at EE’s translation utility?  It helps speed up the process of creating translations- basically using the english ones to show you each term in a file- and replace that term with the proper translation.  If you look at the contents of the system/module folder, each module has a language file- so the ‘weblog’ module folder will have a matching lang.weblog.php language file.  If you hit the ones that match the module names first, you’ll get most of the frontend messages.  Then hit lang.core.php and manually edit the email.php- and that will get another chunk.

There aren’t a ton of frontend EE messages, so that wouldn’t be too bad.  Are you testing one of the trial installs yet?

Hi Robin,

Thank you for the very fast answer on sunday!

Yes, I am trying and evaluating (30 Day Hosted Trial).

Translation utility is really very nice.

But it is a surprise for me that such a differentiation (backend, frontend) is not done in such a good product. I hope you consider this in future versions.

I think this is necessary in a modular approach anyway and this can really help (saves time) the people from other countries and languages much.

You make a good point- and I think I’ve seen the issue come up at least once before.  The way the current utility works, it’s really based on the language files themselves.  However, an easy way to give at least some indication of whether files are frontend or backend might be to add a * type indicator next to any file that has frontend words in it.  While I’m fairly sure some files have both frontend/backend, most are going to be exclusive.  So without making a giant change to the current system, just adding that indicator could likely achieve 90% or what you’re looking for on that one. 

And that’s just me- brainstorming on it.  But yep, I’ll definitely pass the suggestion on to the crew for a way to focus on just the frontend or just the backend language bits.

I think this is a “must” requirement for a lot of projects (at least here in Europe).
Example:
German parent company with branches in 10 countries.
Backend is usually just german and english. But the front end is in 10 different languages. So here you just need to send to front-end-language files to the related countries and let translate. But if you send a mixed one as in EE, it is just unnecessary. Most of them will never be used.

I think, as you said this can be achieved also in EE without changing and doing a lot.

Just wanted to drop a quick ‘heads up’ in case you hadn’t checked out the language packs.  Turkish isn’t in there- but if you’re likely to have multiple languages, some of those will no doubt be helpful.

And I did drop the crew a note on the thread.

For front end translations check out my new extension plugin combination called LG Multi Language

It might be what you are after

For front end translations check out my new extension plugin combination called LG Multi Language

It might be what you are after

Yes and No!

In this topic we talked about language files delivered by EE.

Summary:
I think the backend and frontend language strings should be separated.
Not only for usage but also for keeping the resources modular.

LG Multi Language:
I think your ExtPlug is a layer above that. It seems to be a very good way of translating application specific texts depending on an url-segment or a subdomain.

I planned to use the Custom Text (text string variable loader) plugin of wazdog (Thanks!). Similars things can be done also with this.

In what ways is “LG Multi Language” better than “Custom Text”? (accept the subdomain support and the global variables)

Thanks!

I planned to use the Custom Text (text string variable loader) plugin of wazdog (Thanks!). Similars things can be done also with this.

In what ways is “LG Multi Language” better than “Custom Text”? (accept the subdomain support and the global variables)

I hadn’t seen that extension before. 😊

I guess the main difference between that and mine is that my addon translates text into a default language based on the url or subdomain. The benefit of that is the user doesn’t have to be a member and can change between languages by clicking links.

It also means that the url will be different for multi-language pages which will greatly help with SEO.

I had previously thought of the idea of being able to specify a different language to the one determined by the URL segments or subdomain:

{exp:lg_ml:translate p="my phrase" lang="it"}

and it will probably be included in the next release.

Another feature of my addon is that it works with EE’s pages module. So

<a href="http://mysite.com/my_page">http://mysite.com/my_page</a>

and

<a href="http://mysite.com/my_page/it">http://mysite.com/my_page/it</a>

will render the same page and template. Previously if you added the extra segment the pages module would see that as a different url and not render the correct page.

Cheers Leevi

Also looks like there’s a language-specific version of the Custom String plugin → http://ellislab.com/forums/viewthread/35451/