Akelos Framework v1 forum archive. This forum is no longer maintained. To report bugs please visit https://github.com/akelos/akelos/issues
    • CommentAuthorywarnier
     
    Hi there,

    Since we started to use Akelos, we had a series of problems which, if minor at the time, now begin to generate exaggerated time losses.
    Basically, there are 3 problems that occur when using the translations system a bit more:

    * repetition of terms
    * no hierarchy of terms files (related to first point)
    * no deletion of pruned terms

    Please do not pay attention if my tone might seem a bit harsh in the following description, I am just trying to describe how I see it in the most unaltered way possible.

    Repetition of terms
    ================

    When generating templates in development mode, the new terms added to the templates are automatically added to the corresponding entity's locale file. This is all good while you remain strictly on a completely separate pages model, but once you start playing with menus, you realize that the elements of your menu are generated in each and every entity's locale.

    For example, let's say you manage a list of books, authors and owners, and you want to make a menu show three common links "Books", "Authors" and "Owners". While adding the fields that are proper to each separate entity ("Title", "Publication date", "Address", "Real name", etc), everything works well.
    Now let's say you want to add thos items in the menu. Well, even if you "include" the menu template inside the current page, the page will still belong to one of the entities, and as such each term of the menu will be added to the entitie's locale file.
    When translating only the pages corresponding to these 3 entities, you will find you have to translate "Books", "Authors" and "Owners" 3 times.
    This seems like child's play when mentioning it for 3 terms, but imagine the same for a 200 items-long menu, footer and header list of terms, in the case you have about 20 entities to deal with. That's 3800 useless translations of terms (that can be any number of words). This is time wasted by the translator. In the case of an open-source application, this also results in no translator ever wanting to join the project because we are wasting his time, which is a big problem.

    No hierarchy of terms files
    ======================

    This is related to the first point, in that there is no file considered as a "common" terms list. Implementing that kind of mechanism could be done through a hack of the Ak::t() function in lib/Ak.php that would always load one file called common.php or something like that, and when detecting a variable ocurring more than 2 times while in development mode (I suppose through the use of a common counter for each term somewhere in the development database), Akelos would automatically move the duplicated term to the common.php file (and updated all counters accordingly).
    I think this would make a lot of sense and avoid the huge duplication we have right now.
    This would, of course, involve writing some documentation about it so people understand what's going on (although I think it would be clear enough as is).
    I also, hereby, request formally that this be submitted to vote (if there is any opposition or a better approach suggestion), in order to push it into Akelos core as soon as possible.

    No deletion of pruned/deprecated terms
    ==================================

    Another problem that happens due to the lack of consideration to the translation part is that pruned terms (terms that are no longer used) are not detected, and are left in the translation files. This implies that, for a translator, it is nearly impossible to know what to translate to avoid losing time on deprecated terms.

    Online-translator plugin?
    =====================

    Finally, Akelos would greatly benefit from a shared plugin that allows for online translation (so that some privileged users can update the translations). Of course, this involves editing the translation files, which represents a security flaw, but it could probably be restricted well enough to only give this permission to trusted users. We are looking right now into developing this type of plugin for one of our customers. Any indication of existing base for this or recommendation on how we should do it best is welcome.

    And finally, thank you for the great work on Akelos, it really helps us structure our work and get things done faster, which Akelos is all about :-)
    •  
      CommentAuthorbermi
     

    Hi Yannick,

    on Akelos trunk most of the issues you're facing have been "solved".

    While developing Model Management which is in more than 10 languages and translated by "untrusted" translators, we added name-spacing to translations in order to avoid repetition.

    On the view/helper side, repetition of terms can be avoided by defining:

    define('AK_DEFAULT_LOCALE_NAMESPACE', 'your_app_name');
    

    this will keep a unified namespace for your translations.

    On the modelmanagement project we also used the same for controllers by declaring

    function t($string, $array = null)
    {
        return Ak::t($string, $array, AK_DEFAULT_LOCALE_NAMESPACE);
    }
    

    on the application controller.

    This approach will mitigate most of your issues, plus if you need to structurate your trasnlations better you can even use path-like namespaces like "books/chapters/forms"

    Regarding the online translation, Arno did a really useful plugin for that purpose we are using now on model management. We did not open sourced the plugin yet, but if you're working on the same issue, please send me an email and I'll send you our approach.

    We did not solved the pruned/deprecated terms issue yet, but it would be great if someone contributes this piece ;)

    Thank you for using Akelos for your projects :)

    • CommentAuthorywarnier
     
    Hi Bermi,

    Great! I'm sending you an e-mail right now.

    I would be glad to contribute to the last bit (and also open-source a plugin to translate online).

    Are the changes above the only thing that need to be added to a previous version to get the feature? Obviously not (can't see the change in Ak::t() here). Is there a single commit that I can look for to get the changes and apply them on a previous version?
    • CommentAuthorywarnier
     
    Forgot to mention that we have short deadlines for this, so this should be a swift contribution :-)
    •  
      CommentAuthorbermi
     

    Hi Yannick,

    Check http://trac.akelos.org/changeset/1343 for the required changes, Ak::t() already had support for namespaces, but it does not make use of the global constant.