Own language file for modules

English forums
1

Morning,

when developing a module, how could I use an own language file (e.g. modulname_lang.php) in order to make it easier for users to install this module? When installing a module, chances are good that the cust_lang.php files have already been modified, you know?

Thanks!

2

Just put “modulname_lang.php” in the language directories…

3

nice and perfect! Thanks!

4

do i get it right, that every file in the language directory is read?
What happens, if there is the same TAG in 2 different files. Which one is taken.
Are the files read alphabetically? And the last one wins?
Thank you very much.

5

You should go for your own prefix for all of your modules, this will make Key duplication very unlikely to happen.

‘MYMOD_MYKEY’ => ‘foo’

6

I tried to add a language file into /modules/mymod/out/en/mymod_lang.php but it is not loaded. How can I tell OXID to load my module language file? Or … do I have an error in the path?

7

yes, you have:
/modules/mymod/out/lang/en/mymod_lang.php

8

Thank you. I could include a language file in the frontend this way. But it seems not to be included in the backend. I also tried the paths modules/xyz/out/admin/lang/en/… and modules/xyz/out/lang/admin/…

I just want to translate the labels of the module settings.

9

just have a look at the original template files structure :slight_smile:
out/admin/en/mylang_lang.php

10

[QUOTE=vanilla thunder;101241]just have a look at the original template files structure :)[/QUOTE]

Because that worked so well for the frontend languages? :slight_smile: Ugly system… So many bad design decisions.

Thank you very much. The path worked.

11

[QUOTE=toxid;101272]Ugly system… So many bad design decisions.
[/QUOTE]

Huh? It is practical at the end of the day.

Regards

12

[QUOTE=Marco Steinhaeuser;101276]Huh? It is practical at the end of the day.

Regards[/QUOTE]


if ( defined( 'OXID_PHP_UNIT' ) )
    $this->reply('sure!');
else
    $this->reply('sure?');
13

Hi,

well this is a slightly different topic to lang paths in modules, isn’t it.

But you’re right this stuff doesn’t look very nice. Most likely, a lot of this if PHP_UNIT stuff hung over from former versions and will be deleted step-by-step. So happened in the upcoming version 4.7/5.0: while building the new bootstrap.php, it was massively decreased from 40 appearances in 4.6 to 17 now. Also, OXID eShop has a very high unit test code coverage so we are using PHP_UNIT for edge case functionality testing. I.e. cases which otherwise are not possible to cover with standart php unit. That could be: some cases in exception handling, testing functionality reaching script exit points (where die() is used), very important: protected function testing and so on.

Regards