Loading...
 
Multi-Language Add-In for Visual Studio

Multi-Language Add-In for Visual Studio

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • Ajax Control Toolkit controls

    Posted by buckley on Mon 11 of Jan, 2010 13:34 GMT

    Hello Phil,

    We are using this toolkit from Microsoft heavily on the current project.

    Is there a reason that this cannot work ?

    http://screencast.com/t/NDk1NWFmN

    The addon recognises the Validator but also throws an exception

    http://screencast.com/t/OWM4ZTMx

    Regards, Tom

    Reads: 29962
    Link
    Posted by buckley on Mon 11 of Jan, 2010 13:55 GMT

    The toolkit supports localization so I added the translations in the App_LocalResources folder.

    The addon only shows translations of controls it recognizes (I think). So they don't show up.

    I have another issue now in that I rely on the excel export to list all the strings tha should be translated. If its not possible for the addon to support the Control Toolkit than maybe its an option to extend the addon to show all localized strings in the project and not only the ones that it recognizes.

    Link
    Posted by Phil on Mon 11 of Jan, 2010 21:52 GMT Germany

    Hi Tom,

    I will look into this and reply again in a day or two,

    Phil

    Link
    Posted by Phil on Wed 13 of Jan, 2010 22:54 GMT Germany

    Hi Tom,

    I think that there are two completely separate issues here.

    Firstly, the error message in screencast is coming from an update to the project database in access format. Normally, I do not get this error. However, after playing around for a while, I did get this error as the consequence of a previous error.

    I have a simple recommendation. Stop using the Access format and switch to the XML format. To do this, select the project properties dialog (5th button on the toolbar) and then select the Project Database tab. Here you can select the database format Single XML file.

    The second issue is how to localize the properties of AjaxControlToolkit controls.

    To be honest, at present I don't know. There don't appear to be many attributes which you would want to localize, but you have pointed out two good examples.

    The Add-In uses redirection to look for the Localizable attribute on each property, and only shows the attributes which have this attribute. So far as I can tell, the Localizable attribute is not used at all in the AjaxControlToolkit.

    You said that you added the translations to the App_LocalResources folder. Does this work? Are you using the attribute meta:resourcekey?

    I have tried this out with the TabContainer control (trying to localize the TabPanel.HeaderText property), but up to now with no success. (It should also be possible to see localized versions of the controls themselves, but I haven't got this working either.)

    I know that you know a lot more about ASP.NET than I do, and certainly more about the AjaxControlToolkit. If you understand how to localize these fields, please let me know, because I haven't figured it out yet.

    Phil

    Link
    Posted by buckley on Thu 14 of Jan, 2010 10:32 GMT

    > The second issue is how to localize the properties of AjaxControlToolkit controls.
    >
    > To be honest, at present I don't know. There don't appear to be many attributes which you would want to localize, but you have pointed out two good examples.

    There aren't many to localise thats right. My wisch is that I would like to get a total overview of the strings that should be localised with the addon without a few escaping.

    > The Add-In uses redirection to look for the Localizable attribute on each property, and only shows the attributes which have this attribute. So far as I can tell, the Localizable attribute is not used at all in the AjaxControlToolkit.

    I knew about how you reley on the 'localizable' attribute and thats what it is exactly for. However, it seems that the meta:resourcekey does not require this attribute.
    What if the addon just took every string into conideration? This woul be a generic solution that would solve other future unknown cases. If there are a huge number of false positives (enums that are passed to the web controls as strings for example) than this could be not so good after all.
    If the numvber of false positives is low you can hide them with the moon symbol just fine.

    > You said that you added the translations to the App_LocalResources folder. Does this work? Are you using the attribute meta:resourcekey?

    Yes it does work

    > I have tried this out with the TabContainer control (trying to localize the TabPanel.HeaderText property), but up to now with no success. (It should also be possible to see localized versions of the controls themselves, but I haven't got this working either.)

    > I tried the MaskedEdit control and it worked. If you want you can send me a zip of your test so I can investigate.
    I am now thinking the localize attribute is a nice to have on a property to give it designer support. MAybe the logic is a bit more complicated and there can be requirements for the meta attribut to work.

    > I know that you know a lot more about ASP.NET than I do, and certainly more about the AjaxControlToolkit. If you understand how to localize these fields, please let me know, because I haven't figured it out yet.

    I will asap. CAn you send me your test so I can compare a working solution against a non working?

    Have you also taken this into consideration?
    "I have another issue now in that I rely on the excel export to list all the strings tha should be translated. If its not possible for the addon to support the Control Toolkit than maybe its an option to extend the addon to show all localized strings in the project and not only the ones that it recognizes."

    I would basicaly like to make the addon my one and only solution for everyting licalizable and not be surprised by exceptions. Note that the addon in its current state goes very far and I bless myself I dont have to do this work manualy.

    Regards, Tom

    Link
    Posted by Phil on Sat 16 of Jan, 2010 10:36 GMT Germany

    Hi Tom,

    can you try out the latest version (4.65.0059).

    I have added a new option to the setup dialog, in the (new) Web tab.
    Image
    Fairly obviously, you can use this option to include properties in the scan, which do not have the Localizable attribute.

    I specifically exclude the runat property and any event handlers.

    I totally agree about handling additional resources and I intend to add this feature immediately.

    I will try to pack up my test project and send it to you to day, but first I have a bunch of (non programming) stuff to do.

    Phil

    Link
    Posted by buckley on Tue 19 of Jan, 2010 11:03 GMT

    Hello Phil,

    The properties that should be localizable but weren't (because lack of attribute) are now recognized with the new build. Nice!

    Here is a video of a couple of issues I ran into

    (Im looking a few seconds how to stop the video, sry for the noise there)
    http://screencast.com/t/YjFiNjE2YTY

    You will see that

    1. The addon throws an error if I ask it to go to the translation row if I have my focus in the editor.
    => It works if the tree is open for that row somehow

    2. The new attributs (that don't have the attribute) cannot be hidden. The moon/sun icon does not work for them.

    Also, I see that the number of false positives is very low. Except that the text attribute is being considered by the addon where it shouldn't. IMO the algortim should take into consideration all the properties that are localisible and also do a check if they are used by the developer.

    I hope this video makes that clear :

    http://screencast.com/t/ZmZlOWJlO


    Regards, Tom

    Link
    Posted by Phil on Tue 26 of Jan, 2010 23:20 GMT Germany

    Hi Tom,

    I have fixed the problem in the go to line function in version 4.65.0062. Did you know that you can also access this function via the context menu in the editor window?

    The sun/moon icon does not work to hide an item, if it is selected for translation. If you deselect it - by clicking on the check box - you should then be able to hide it.

    Do you think that that is a reasonable restriction? Of course, it would be better to give some visual clue that the function is effectively disabled, such as removing the sun icon (or making it grey!)

    I need a little more time to look at the problem in the second video.

    By the way, the latest version has support for additional resources, which I have described in another forum posting (but not yet in the help file).

    Phil

    Link

    Posted by buckley on Wed 27 of Jan, 2010 08:36 GMT

    Hello Phil,

    "I have fixed the problem in the go to line function in version 4.65.0062. Did you know that you can also access this function via the context menu in the editor window?"

    => I did not know this and it comes in _real_ handy. This build seems like a solid release.
    This feature can be improved if the addon gives focus to the page in the addon pane even if there is no corresponding translatable text. Currently there is the dialog "Selected line does not contain a string".
    This would allow the devlopper to quickly jump to the correct node in the tree in the context of a page opened in VS.

    "The sun/moon icon does not work to hide an item, if it is selected for translation. If you deselect it - by clicking on the check box - you should then be able to hide it.
    Do you think that that is a reasonable restriction? Of course, it would be better to give some visual clue that the function is effectively disabled, such as removing the sun icon (or making it grey!)"

    => Right, this makes perfect sense now. I should have thought a bit harder before reporting this.

    I opt for just removing the sun icon. (I used greyed out elements in the GUI to notify the user something is possible once he alterted the state of the system. We start with the sun visible so we don't hide a feature from the user)

    "
    I need a little more time to look at the problem in the second video.
    "

    => Ok, let me know if you need more input. Its not a blocking issue.

    "
    By the way, the latest version has support for additional resources, which I have described in another forum posting (but not yet in the help file).
    "

    => Thread is at
    http://www.jollans.com/tiki/tiki-view_forum_thread.php?comments_parentId=411&topics_offset=2&topics_sort_mode=lastPost_desc&forumId=1

    Regards, Tom

    Link
    Posted by Phil on Wed 27 of Jan, 2010 22:59 GMT Germany

    I have just uploaded a new version (4.65.0064) which:

    • does not show ASP tags which have no text and no attributes with text
    • does not show the sun icon for selected nodes
    • sorts the component nodes


    Even when the sun icon is not shown, there is still a special context menu on this column, which is harmless, but feels wrong. I might change that.

    Phil

    Link

    Posted by buckley on Wed 17 of Feb, 2010 17:14 GMT

    Hello Phil,

    Today I had some time to work with the addin and can give feedback on the feature that the tool now per default shows all string properties as translatable as opposed to only the properties that are marked with the localizable attribute.

    The dilemma is that this new feature is very welcome as it picks up strings that would otherwise go undetecte but I was was hoping that it would not pick up too much stuff that is irrelevant for translations ("false positives"). But in my current project it does.

    Please have a look at the following screenshot :
    http://screencast.com/t/OTEzNTM4

    Only 2 (marked yellow) are suitable for translations and the rest is not.

    New users will find all of these false positives confusing. I on the other hand appreciate the feature and will use the feature.
    I would give new users precedence however, as they still have to find their way in the tool.

    Maybe you will get some feedback from other users on this so that you can make the right decision.

    Maybe the default should be only localizable defaults and the switch should be visible on the grid instead of hidden away in the configuration. This would make the feature more discoverable when new users also found out that they are missing strings.

    Link


    Posted by buckley on Mon 22 of Feb, 2010 14:58 GMT

    Hello Phil,

    What do you think of the following solution for the false positives. Keep the default to all attributes (as is currently the case) and moon/disable the attributes that don't have the localizable attribute. This way not strings are missed and the user can hide them with the interface.

    Regards, Tom

    Link

    Posted by j.rewera on Tue 30 of Mar, 2010 11:56 GMT

    We have some further serious problems with the Add-In. Files with certain translations (around 4000) were sent to the translators (Excel export), and at the moment, we are re-scanning project, this time using the option 'Show all text properties' (scanning AjaxControlToolkit controls used in project which were not included until now).

    We work in the following way: we select the items to be translated in the control tree (ASP/.HTML Tab) and few times a day we protect our work by saving the solution in Source Control. When we reopen the Add-In and execute scanning (there is no other option) but the items on the list do not display correctly!

    For example after getting last correct version from SC and re-scan:
    1) Add-In changes IDs that were are already assigned. Ex: “Hello” string had the id 3 and after reopening program gives it new ID: 1538. Previous ID is already in translation file sent to translators so we don’t’ want that change!

    2) Items previously (before check-in) not selected, after the re scan are automatically checked by the program. Ex: “CssClass” are now checked which we don’t want to translate!

    3)The program removes given names (in the column 'Name') and treats 4 different strings as one (example in screenshot) – those items cannot be then modified – we cannot check or uncheck them!

    This is a serious problem for us. We cannot continue working with the resources. We are afraid that running program with this bugs will change or destroy StringIDs already sent to translators and they will import incorrectly.

    Any ideas?
    Regards, Jake

    addin.PNG (27.11 Kb)
    Link
    Posted by Phil on Tue 30 of Mar, 2010 19:51 GMT Germany

    Hi Jake,

    I think that I may have fixed this problem already. Which exact version are you using? Can you try installing the latest version, if you are not using it already?

    I am sure that the problem is related to the fact that the grid shows multiple properties with the name ".HeaderText", without showing the name of the control.

    My guess, is that the problem only occurs if you use flat list mode. If you select "Structured List" from the menu below the +- symbol (and possibly rescan the project) it might help.

    Phil

    Link

    Posted by j.rewera on Wed 31 of Mar, 2010 14:12 GMT


    Hello Phil

    Thanks for quick response!
    We use this version: 4.65.081 and you are right about flat/structured list, after out tests this seemed to be the main reason program acted problematically. We did the re-scan but we still cannot check/uncheck some of the items that had hidden prefix or have had their ID changed? Any idea how fix this?

    J.

    Link