Hallo

I'm testing the Lussumo board at the moment and like it very much. I'm an eager user of phpbb boards on my homepages.

I was thinking of starting a danish community board on my own homepage. Is it legal to do that. E.g buy lussumo.dk

The community will contain a board and a download section with the danish translations of extensions

Anders

Or more simple: create a category on this board for each language, as soon as requested by members and one is ok to moderate it.
It's easy for readers to block the categories they are not able to read.
The step beyond is activating languages add-on, for each new i18n category. Maybe use my own LanguageSelector extension+ ? That way readers can have interface in their language and at least a category to read.

It's much simpler to setup than a separate forum for each language and more open also for polyglot readers.

Sounds pretty cool. I had a bit the same idea than Anders a while ago, but a whole different site for each language would probably divide the community, and it would be rather difficult to keep track of everyone's activity. Using Max's Language Selector addon on lussumo.com would make things easy for everyone.

Count me in if you need some help, I'd be glad to give a hand for the french category.

"Or more simple: create a category on this board for each language, as soon as requested by members and one is ok to moderate it."

good idea, but imagine 20 other languages mixed with english? you could exclude these categories but ...
I would prefer something like

lussumo.com\int

lussumo.com\global

From my point of view, I can't help anyone in any language but English for my extensions. The auto-translator thingy might work, but given how informal/technical most forum language is (at least in English) they might output complete gibberish. I know this doesn't help any, but I don't have a better suggestion :/

I think a two pronged attack for translating Add-ons would be good.

1. Encourage translations to go in a specific add-ons directory using language codes, something like add-on-name/languages/en.
2. Allow general language packs to translate add-ons as well, but be overridden by any languages in the extension directory.

Would this work? Hopefully this way, if an extension author is unresponsive, the general language pack can take up the slack, as those doing the language pack are far more likely to be the people translating the add-ons I would have thought.

This is all applicable to specific extension styles for different themes/styles actually :)

The problem is with the use of several languages on the same forum.

• /conf/language.php can't be used; you would need one for each language.

  Max_B can do that by setting something like that in his extension.

• Extensions need to set default definitions (using SetDefinition() you don't overwrite already set definition) for each languages that the extension author can translate his definitions to.

  Extensions definition could be set in /extensions/<extension>/language/<language>/definitions.php, and to use the good definitions, you would have something like that in extension code:

  define('THIS_EXTENSION_PATH', dirname(__FILE__) . '/');
@include(THIS_EXTENSION_PATH . 'language/' . $Context->Configuration['LANGUAGE'] .'/definitions.php');
include(THIS_EXTENSION_PATH . 'language/English/definitions.php');

All that doesn't need any change in the core. that just need a change in extension author practices (+ a wiki page that explain it).

I havn't read the post on VanillaDev. That would a good solution, easy for authors.

Summary of this post:
I would suggest here the way how to solve all language issues of Vanilla by small and non-violent core change
As an addition some my thoughts and plans concerning language issues
The point of this comment is bold formatted
My thanks to all of you!

Thanks to Max_B I found this discussion. I would like to say, it would be great to solve language issues of Vanilla once and forever.

I'm rather going to talk more about i18n of any Vanilla install than just of this particular community forum.
Some of you have probably noticed I've had already become involved in this issue by talking a lot about it and also by developing yet two add-ons concerning language issues. Yes, I'm not english native ;-)

So maybe it would be better to make some summary of my thoughts at this moment and sorry it is so long :) Some of it has been already told by some other people here and there, some of it has been already mentioned by me somewhere.

First I should formulate my needs, which I think might be needs of others too:
1. I need completely switchable Vanilla UI with its extensions to a language according to a user settings without doing any core hacking.
2. As an option to a user I need there to be a way to setup language priorities so if there is something not translated into a language with the highest priority it goes through languages in your priority list and loads it, ending on the standard english dictionary if nothing is found.
(Browsers allow you to setup language priorities - that's kind of precedence)
3. I need also comments to be able to translate to other languages and display them according to user defined language priorities and available translation of the comment

At the moment I work on #1 and here are my thoughts:

LanguageSelector is nice extension supporting all of this, but actually there is a core hack necessary and it doesn't solve extension translations automatically - you need to do some other coding.

Actually there are only two issues I cannot do myself.

One issue (already mentioned here) is that extensions (especially the old ones) doesn't use SetDefinition() way and it overdefines any language definition loaded before. I know it is not possible to make all add-on developers to fix this and make them upload new version of the add-on, so I made FixLanguageDefinitions extension, which only brings you a bash script seding all default.php files and fixing this thing. Any suggestions and improvements to the script are welcome.

Second issue is that any language selecting needs core hacking and I suggested to do something with it in some another comment but that suggestion won't work nicely with priorities, because it loads definitions.php of a main language and there is no way how to avoid it and rewrite it in a different way.

Now the language loading in the core looks like this:
include($Configuration['LANGUAGES_PATH'].$Configuration['LANGUAGE'].'/definitions.php');
include($Configuration['APPLICATION_PATH'].'conf/language.php');

I would maybe suggest better way then I did before and it is this core change:
include($Configuration['APPLICATION_PATH'].'conf/init_language.php');
include($Configuration['APPLICATION_PATH'].'conf/language.php');
where content of conf/init_language.php as default would be just:
<?php
include($Configuration['LANGUAGES_PATH'].$Configuration['LANGUAGE'].'/definitions.php');
?>

So it would be compatible with any configuration from old version (if done any custom change of conf/language.php).
And I think that core change would be the only change in Vanilla needed. Everything else can be done by add-ons.
Since conf folder is writable by add-ons, it would be possible to install/alter any code there by an extension self.

I made this add-on ExtensionLanguageLoader which is installing some code into conf/language.php and going through places where might be found extension translations and loads them. If the suggestion I made above would be implemented then I could easily add a code into conf/init_language.php rather then to conf/language.php

If I improve Language Selector (ad #2) by ability to choose multiple languages, I can replace (it might be done automatically by an extension self) the default
include($Configuration['LANGUAGES_PATH'].$Configuration['LANGUAGE'].'/definitions.php');
by handling of priorities and load the definitions beginning with language with the lowest priority

Also there are two persons/ways adding an extension translation:
A. extension developer in extension release
B. language translator in language add-on release

Without knowing what Stash suggested about this I made the ExtensionLanguageLoader add-on to load definitions from (in order of loading):
extensions/*/LANGUAGE.php
extensions/*/translations/LANGUAGE.php
languages/LANGUAGE/extensions/*.php
conf/LANGUAGE.php

So if A is your case and you want to add for example Spanish translation to your extension release, then you use extensions/YOUR_EXTENSION_FOLDER/Spanish.php or extensions/YOUR_EXTENSION_FOLDER/translations/Spanish.php

If B is your case and you do for example Spanish add-on you save the extension translation into languages/Spanish/extensions/EXTENSION_NAME.php or you can save all extensions' translations in languages/Spanish/extensions/WHATEVER_GLOBAL_NAME.php

JFYI at the moment I'm working on improvements on this add-on optionally allowing caching of the language definitions because I guess it's not fine to search all possible places always when Vanilla is run. Also I'm thinking about caching at the user level (not exactly user level, but user settings level, so if two users have the same language settings there will be same cached data used). If this is cached then there might be done more deep search of possible definitions (search for spanish.php not only Spanish.php and also search it in other extension subfolders than translations)

More to #2.
The point of prioritized languages is not only in extension translation not available in UI language. As I said I'm thinking also about loading basic language definitions and load more than one language definitions to fill gaps in translations.
Let's say my language priorities are cs, sk, eo, en, sgn-cs, sgn-us, ru, si. I really would like to see rather slovak or esperanto translation then english one and I would rather see czech sign language translation than russian one (yes there is a way how to write sign languages and yes sign language is not international, there is plenty of them but they have very similar grammar)

Considering caching of this too, so it won't load all definitions in a priority list, but just some cached dictionary resulted from loading of all definitions from the list.

Also it would be maybe nice option to display along the displayed definitions not being in the highest priority language a language code indicator so viewer wouldn't be confused by mix in many languages. Another then main language definitions just would be prefixed by "(LANGUAGE) " where LANGUAGE would be the language add-on name or rather $Context->Dictionary['XMLLang'] of the language.

Ad #3.
Also as I wrote in some other thread I'm going to write an add-on allowing to translate comments either so the content of the forum would also work with priorities and it would switch the content according to viewer's needs - this is for completely multilingual forum, but also if you use vanilla to turn a discussion into blog, you can have the blog multilingual. Also I'm thinking that vanilla might be used as a simple CMS, so the content switching might be useful for this either.

There might be a permission "able to edit translation" so it would be possible to create a translator role which would be able to edit content in other languages but those written by author.

To make #3 more doable (because it seems to be impossible to translate all the content):
- I almost finished CommentSummary add-on, so if any comment is long you can use optional summary field so it could be enough to translate only this one if translators are busy.
- I'm going to create/use some add-on allowing vote on discussions and comments so translators can focus on discussions and comments with higher ranking first.
- I'm going to use one inter-language to make the necessary amount of translators linear growing if added a new language (not exponentially growing if used each language pairs), BTW esperanto suits very well to be the inter-language :)


I'm open to any suggestions and ideas!
Thanks for reading the whole story :)
And thanks to all people from this great community. It's nice to be here. :-)

JFI: I released a new version of Extension Language Loader which is now able to read language priorities settings and loads all necessary language definitions, there is also a cache mechanism, so it doesn't search in all possible places of translations every time Vanilla is refreshed/called. More information on the add-on page.
And Just for reference I also released a new version of Czech language add-on Cestina, which contains also translations of some extensions and it is loaded by this add-on.

So #1 and #2 are implemented now. Just need to implement ability to set language priorities at user level. I'm going to improve Max_B's Language Selector to do this as an option to its current funcionality.
#3 is gonna be huge :-)

Still the suggested core change would be nice, that anybody could install language selector add-ons just by enabling it.

after reading whole thread i think the best would be a change in core of forum
to read translations from extensions/MY_EXTENSION/languages/.

Code should check for translation in current language code - simplest way is LANG_CODE.php, so default would be en-ca.php
Also code chould check if this default file exists, and if not then error msg should appear.

This will force extension developers to do it the right way.

Translations will resolves to translate lang file whitch in fact contains
$Context->SetDefinition('key', 'value');
$Context->Dictionary['key'] = 'value';

Later translations could be sticked to the extension page.

The part im still mising in my mind is upgrade of extension (with provided translations) to newer version
and putting somewhere info about outdated 3rd party translations. (i know nothing about updating of plugins atm :) )

For now i can think only of method whitch i posted here: http://lussumo.com/community/discussion/8731/extensions-internationalization
(waiting to move it here by mod/admin ... thanks :) )