Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 55

Thread: Ext.LocaleManager

  1. #41
    Sencha Premium User vadimv's Avatar
    Join Date
    Sep 2010
    Location
    Cluj, Romania
    Posts
    811

    Default

    Quote Originally Posted by koblass View Post
    Hi,

    What would be very nice is the ability to dynamically change the locale without any need to restart the application.

    Daniel
    +1, would be great.

  2. #42
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,450

    Default

    Thank you for explaining... this got the creative juices flowing

    Quote Originally Posted by koblass View Post
    One important thing, is that the translation loading needs to be "on demand".
    In order to perform this the LocaleManager is in charge of creating the LocaleBundle when requested and load asynchronously the translation regarding the locale. During this phase (when the translations are not loaded), the "getString" and "getFormattedString" method of the LocaleBundle return a default text (that should be present in the main LocalBundle for instance), like "Loading...". Then when the content of the LocaleBundle is loaded the "change" event should also be fired on this LocaleBundle object, so that the components who access to those translations can update themselves.
    Not sure I like having the text "Loading...", I think having the default (or user pref specified) locale text there at app startup is the correct way to do this. For web applications, you really shouldn't need to reload locale often. 90% of the time, it will be on default and the only time it will change is if the user selects to change it. After that it should be saved in user preferences. Web sites you would need to but that's not really what Ext JS (or my mindset) is geared towards.

    Quote Originally Posted by koblass View Post
    So basically, we should have 4 distinct classes. A Ext.LocaleManager, Ext.LocaleBundle, Ext.LocaleProxy and Ext.LocaleReader. (change the names accordingly of course)
    Agree with Ext.LocaleManger and Ext.LocaleBundle but I'm not sure a special proxy and reader are needed. That's another can of worms on trying to make something that works for many use cases. I would rather leave that part up to the individual devs to create but I do agree that Ext.LocaleManger should be more aligned with the data package.
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

  3. #43
    Sencha User
    Join Date
    Mar 2010
    Posts
    51

    Default

    Hi Mitchell


    Not sure I like having the text "Loading...", I think having the default (or user pref specified) locale text there at app startup is the correct way to do this. For web applications, you really shouldn't need to reload locale often. 90% of the time, it will be on default and the only time it will change is if the user selects to change it. After that it should be saved in user preferences. Web sites you would need to but that's not really what Ext JS (or my mindset) is geared towards.
    I don't agree with you on this point :-)
    I do agree on the fact that the users rarely change the language of the app, but what is the default translation ? The English one, the French one, the... ?!?!
    Of course I could load the translation file regarding the user profile at start up of the app, but this is ok for small apps... What about modular apps that loads portion of code (portion of the app) dynamically ? In this case you'll also have to load the translations dynamically and in this case the "default" translation will have to be in a chosen language, which generally is English. As a final user, I rather prefer to have a "Loading..." text everywhere for half a second and then the translated labels in my language.
    But why not having the two options ? The second parameter of the getString method could be the "default" text and/or this could be configured in the main LocaleBundle (I don't like the idea of having it as a config option, because once again this won't be localized...


    Agree with Ext.LocaleManger and Ext.LocaleBundle but I'm not sure a special proxy and reader are needed. That's another can of worms on trying to make something that works for many use cases. I would rather leave that part up to the individual devs to create but I do agree that Ext.LocaleManger should be more aligned with the data package.
    The problem there is that the LocaleManager will be in charge of loading the LocaleBundle on demand. So the LocaleManager has to know how to load the data/translations from the backend, so a proxy will be required there... And if we have a proxy there, why not having a reader that would give more flexibility or the data representation ? Could by nice to be able to load ini files or json files directly from the server for instance...

    Best regards
    Daniel

  4. #44
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,450

    Default

    Quote Originally Posted by koblass View Post
    I don't agree with you on this point :-)
    I do agree on the fact that the users rarely change the language of the app, but what is the default translation ? The English one, the French one, the... ?!?!
    Of course I could load the translation file regarding the user profile at start up of the app, but this is ok for small apps... What about modular apps that loads portion of code (portion of the app) dynamically ? In this case you'll also have to load the translations dynamically and in this case the "default" translation will have to be in a chosen language, which generally is English. As a final user, I rather prefer to have a "Loading..." text everywhere for half a second and then the translated labels in my language.
    But why not having the two options ? The second parameter of the getString method could be the "default" text and/or this could be configured in the main LocaleBundle (I don't like the idea of having it as a config option, because once again this won't be localized...
    It's ok to disagree... discussion will only bring all sides to the table to make something better than one of us could make. Default language is whatever the developer sets the initial language too. Some people can set the language to English, some to French. About modular apps... currently not supported within Ext JS 4 so therefor I cannot guess how we will be doing it so I don't want to put forth effort on something that I would probably have to change later. I currently have default text as an option in the get method and will be keeping this no matter what direction this manager goes.

    Quote Originally Posted by koblass View Post
    The problem there is that the LocaleManager will be in charge of loading the LocaleBundle on demand. So the LocaleManager has to know how to load the data/translations from the backend, so a proxy will be required there... And if we have a proxy there, why not having a reader that would give more flexibility or the data representation ? Could by nice to be able to load ini files or json files directly from the server for instance...
    Ext.LocaleManager will have it's own "API" of sorts... will publish the fields it needs and then you can create your proxy/reader to adhere. Working at Fortune 100 clients, you don't really have a say on what the data looks like. The TreePanel is a great example, very rarely do I get the text and leaf that I need, I always have to hook into processResponse to change the incoming JSON/XML into what the TreePanel/TreeLoader needs. So I see it being that people will override the proxy/reader to use their own and do mapping or convert or whatever they need.
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

  5. #45
    Sencha User
    Join Date
    Mar 2010
    Posts
    51

    Default

    Quote Originally Posted by mitchellsimoens View Post
    Default language is whatever the developer sets the initial language too. Some people can set the language to English, some to French. About modular apps... currently not supported within Ext JS 4 so therefor I cannot guess how we will be doing it so I don't want to put forth effort on something that I would probably have to change later. I currently have default text as an option in the get method and will be keeping this no matter what direction this manager goes.
    Well, sound ok to me, but could it be possible to define a global default translation if no default translation have been added to the get method ? Like this our two options could coexist :-)

    Ext.LocaleManager will have it's own "API" of sorts... will publish the fields it needs and then you can create your proxy/reader to adhere. Working at Fortune 100 clients, you don't really have a say on what the data looks like. The TreePanel is a great example, very rarely do I get the text and leaf that I need, I always have to hook into processResponse to change the incoming JSON/XML into what the TreePanel/TreeLoader needs. So I see it being that people will override the proxy/reader to use their own and do mapping or convert or whatever they need.
    Sounds good to me too to use a processResponse method that you can overwrite.

    I'm very excited to be able to test your solution :-)

    Best
    Daniel

  6. #46
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,450

    Default

    Quote Originally Posted by koblass View Post
    Well, sound ok to me, but could it be possible to define a global default translation if no default translation have been added to the get method ? Like this our two options could coexist :-)
    By default, Ext.LocaleManager will default to English. You will have a way to set a default language in the app. You will also have the option to specify default text in the get method (just in case server goes down or that particular locale isn't in the database).
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

  7. #47
    Sencha User
    Join Date
    Mar 2010
    Posts
    51

    Default

    Quote Originally Posted by mitchellsimoens View Post
    By default, Ext.LocaleManager will default to English. You will have a way to set a default language in the app. You will also have the option to specify default text in the get method (just in case server goes down or that particular locale isn't in the database).
    I think that this solution is just perfect.

    I've just one question in mind right now...
    - As we can define "default" translations as a second parameter to the get method. Let say this default translation for my app is in English. Then loading a locale file for this translation is not needed, how do you plan to handle this ?

    Best
    Daniel

  8. #48
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,450

    Default

    Quote Originally Posted by koblass View Post
    I think that this solution is just perfect.

    I've just one question in mind right now...
    - As we can define "default" translations as a second parameter to the get method. Let say this default translation for my app is in English. Then loading a locale file for this translation is not needed, how do you plan to handle this ?
    I try not to require too many things. Default text should only be used for error handling (load fails) but if someone doesn't want to load a bundle for the default language, their option. I will say, it is much easier to manage and scale if you keep all locales in the same spot, a database (or however you store it) instead of hunting through your JS code to change default text.
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

  9. #49
    Sencha User
    Join Date
    Mar 2010
    Posts
    51

    Default

    Quote Originally Posted by mitchellsimoens View Post
    I try not to require too many things. Default text should only be used for error handling (load fails) but if someone doesn't want to load a bundle for the default language, their option. I will say, it is much easier to manage and scale if you keep all locales in the same spot, a database (or however you store it) instead of hunting through your JS code to change default text.
    I agree once again, but would it be then possible to have more events, like "beforeload" and "load" on the LocaleManager ? The "beforeload" event could do the trick if needed as it could be canceled and then the locale resource wouldn't be loaded. So the problem could be solved if require...

    What do you think ?

    Best
    Daniel

  10. #50
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,450

    Default

    Quote Originally Posted by koblass View Post
    What do you think ?
    Already ahead of you At a client location during day so won't be able to work on my/our ideas till evenings.
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

Page 5 of 6 FirstFirst ... 3456 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •