Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options
Lussumo community in other languages
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
0
This discussion has been closed.
Comments
Sorry I didn't respond to your email sooner - I'm very busy.
I haven't trademarked the name Lussumo- only copyrighted - if that is what you are asking.
I won't be able to help you out very much because (a) I don't speak your language and (b) I have a hard enough time running and English-speaking one.
Something else that has crossed my mind is that it might be a better idea to keep all of the various language support forums on the lussumo.com domain. So your language would be something like lussumo.com/dk/discussions. This way people would only have to register at lussumo.com/community and have access to all of the different languages they happen to speak. If you would like me to set something like that up and give you admin capabilities in the forum, I'd be open to that idea.
For that matter - I'd kind of like to hear what all of the other non-english-native-language-speakers have to say about this.
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.
I guess the other thing to consider is the add-ons site:
I was thinking that I'd create a translation tool that allows people who speak other languages to work on translations for the add-ons site. Once a translation is complete, it can be applied to the site with a selector somewhere (saved in your community prefs if you are a member). The problem that arises is the support discussions for each add-on...
Count me in if you need some help, I'd be glad to give a hand for the french category.
You know what would make a cook add-on?
Set up the community like Max recommended with different categories for different languages.
Use Max's Language Selector like Ø said, as well.
Then for any non-english-speaking person that asks for help, have a new option on each comment that allows you to translate the text into your language. I bet we could use babelfish somehow to do the translation on the fly with some nice ajax/javascript.
hmmm...
Add-ons translations are a problem. Mark do you read/remember a discussion on Vanilla Dev about my suggestion to keep extensions translations in the extension folder, named from the language? That's the way I have set up my install. But this is of topic, about support:
I'm not very confident in babelfish for technical issues. I rather suggest that, if an admin is unable to read/write english in the add-on discussion, (s)he could ask in his language category for a kind soul to relay it?
- Encourage translations to go in a specific add-ons directory using language codes, something like
- 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.add-on-name/languages/en.This is all applicable to specific extension styles for different themes/styles actually
Vanilla read first /languages/<language>/definitions.php
then /conf/language.php
then the definitions in extensions.
Vanilla and the extensions have to let admins to adapt the definitions to their uses. That what /conf/language.php is for.
Admins shouldn't have to do that by changing the definitions inside each extensions. The changes will be lost each time you update the extensions, and that will be a pain to have to open each extensions to change a definition...
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)./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');// Enabled Extensions @include($Configuration['EXTENSIONS_PATH']."RSS2/{$Configuration['LANGUAGE']}.php"); include($Configuration['EXTENSIONS_PATH']."RSS2/default.php"); @include($Configuration['EXTENSIONS_PATH']."CategoryJumper/{$Configuration['LANGUAGE']}.php"); include($Configuration['EXTENSIONS_PATH']."CategoryJumper/default.php"); @include($Configuration['EXTENSIONS_PATH']."PanelLists/{$Configuration['LANGUAGE']}.php"); include($Configuration['EXTENSIONS_PATH']."PanelLists/default.php"); //etc...The supplemental include is automatically added by a small patch to the core, that was the question/suggestion to Mark on the dead VanillaDev discussion.If one does not want to touch the core this edit is easy, by hand.
All extensions should use SetDefinition().
Also not that I don't see the need for a supplemental language level in extension if definition files are named trough the language.
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
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.phpSo 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. :-)
I'm waiting for feedback from bugtracker before adding it to SVN
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.
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