Yes, sounds about right - maybe you know about a tutorial that shows this step by step?
Wanted to have that in all client projects but still haven't found the time to implement it,
but i'm going off topic here.
--
mit freundlichen Grüßen
Alexander Kludt

__________________________
Phone: 09283-5925453
Fax: 09283-592671
Skype: kingschnulli
Email: [email protected]
Website: www.aggrosoft.de

__________________________
Aggrosoft it intelligence GbR
Tannstrasse 12
95111 Rehau
GERMANY

Sitz Rehau, Amtsgericht Hof
Steuernummer: 223/165/54508
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773

___________________________
Diese Nachricht ist nur für den Empfänger bestimmt, sollten
Sie nicht der Empfänger sein löschen Sie diese Nachricht
umgehend und geben Sie uns bitte per Email ([email protected]) Bescheid
über den fälschlichen Erhalt.


Freitag, 1. März 2013 14:00
Hi,

well yes, transferring translations to the database sounds like an idea. Alone, I can't see any advantage from a technical point of view to change the existing system and put effort on it at this point.

Just an idea to fit the needs of your clients:
oTranCe is a free and open source system that is made exactly for the purpose you're looking for. Until now, it cannot handle database entries yet but it shall not be too complicated to write your own importer extension for it. You'll find a German tutorial here:
http://it-republik.de/php/artikel/Uebersetzungen-von-Anwendungen-verwalten-5405.html

oTranCe is easy to install and can be used in your client's projects as well. Just define the templates for cust_lang.php, make an initial import of the entries and off you go. No hassle for your client with FTP, forgotten semi colons or character set. After changing language keys, export the files to the server and connect a routine that copies this ready-to-use files from the export folder in oTranCe to your live shop installation. oTranCe is also able to work with SVN (and with Git soon: https://mysqldumper.jira.com/browse/OTC-200)

So it doesn't matter if translations, little changes etc. shall be done in shop admin or in a tool besides, right? :-)

You'll find more information (demo, wiki, etc) about oTranCe on http://otrance.org


Cheers
Marco



From: [email protected] [[email protected]] on behalf of Alexander Kludt [[email protected]]
Sent: Friday, March 01, 2013 11:47 AM
To: [email protected]
Subject: Re: [oxid-dev-general] cleaning OXID eShop translations

Hi,

+1 for Marat's idea - everytime a customer (shop owner)  needs to be able to change language
stuff we need to transform it into a CMS content so he can do that in the backend. Most people
just don't get it how to edit a file through FTP. Sounds like this might be done through oTrance, marco?


_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
Freitag, 1. März 2013 11:35
Hello,

+1 for Alexander's idea

and it would be awesome if you could move the lang keys managemet into the database.
Perhaps there would be a table like with lang key, language, default translation and a custom translation, and the languages can be cached into the temp file. It makes the whole translation process and adding custom keys a lot easier, cause the user can simply translate the stuff in backend instead of searching and editing some php lang files.

Greeetz
Marat



_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
Freitag, 1. März 2013 11:06
Hi there,

Maybe this is already been done, but having parameters inside the translations would make things a lot easier.
Like this:

'MY_LANGUAGE_VAR' => 'You have :count items in your cart'

[{oxmultilang ident="MY_LANGUAGE_VAR" count="5" }]

gives

You have 5 items in your cart



Freitag, 1. März 2013 08:58

 

Hello everyone,

 

We are working on OXID eShop translations. We are optimizing language constants: removing duplicates, removing colons ’:’ from constants. Colons will be placed in template files. Also, mapped constants will be replaced with generic ones.

 

Is there any other suggestions we could use to improve multi language handling ?

 

 

Tadas Rimkus 
Software Developer 

[email protected]
Fon +49 761 36889-0
Fax +49 761 36889-29
www.oxid-esales.com



_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

<<attachment: coding.vcf>>

_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general

Reply via email to