Blog Documentation Book a Demo
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.

Lussumo community in other languages

Anders_AarhusAnders_Aarhus
edited October 2008 in Vanilla 1.0 Help
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

Comments

  • MarkMark Vanilla Staff
    edited March 2007
    Hello Anders,

    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.
  • Max_BMax_B New
    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.
  • MarkMark Vanilla Staff
    edited March 2007
    That's a great idea, Max.

    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...
  • SlashedZeroSlashedZero
    edited March 2007
    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.
  • DinoboffDinoboff
    The addons need to be upadted to use $Context->SetDefinition(); and the extensions definition need to be added to the language files (except for the English one).
  • ToivoToivo New
    "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
  • MarkMark Vanilla Staff
    Toivo got me thinking:

    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...
  • StashStash ✭
    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 :/
  • Max_BMax_B New
    I don't think we'll end up with 20 languages. I'd bet that only a handful will be needed, given a minimum threshold for keep it alive.

    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?
  • StashStash ✭
    edited March 2007
    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 :)
  • DinoboffDinoboff
    edited March 2007
    NO, that wouldn't work for the second point.

    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...
  • DinoboffDinoboff
    edited March 2007
    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).
  • Max_BMax_B New
    In fact, here is an excerpt of my current extensions/languages setting, trough conf/extensions.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.
  • DinoboffDinoboff
    I havn't read the post on VanillaDev. That would a good solution, easy for authors.
  • icoutoicouto
    @Mark: providing people with an interface for producing their own translations of extensions - and, if possible, of Vanilla Core - would be FANTASTIC! I also welcome the idea of seeing Language Selector used in this forum. It will show Vanilla to be the truly international tool that it is, and will enable people to see first hand how wonderful it looks (and works) in a variety of languages.
  • klipklip New
    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. :-)
  • Max_BMax_B New
    Suggested modification to the core is minimal.
    I'm waiting for feedback from bugtracker before adding it to SVN
  • klipklip New
    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.
  • DinoboffDinoboff
    The only problem with putting extension translations in something like "extensions/<ExtensionName>/languages/<LanguageName>/definition.php" is that it would only be good if extension authors wanted to support the translation of their extensions. They won't. Translators won't do it either. The only one who can do it is the forum admin for its own forum; and putting the extensions translations in the language or extension folders will make updating vanilla and extension more difficult.
  • TothAmonTothAmon New
    edited October 2008
    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 :) )
This discussion has been closed.