[ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-2969: --------------------------------------- Fix Version/s: 3.0.0.cr1 3.0.0.GA Assignee: Viacheslav Kabanovich Sean, unfortunately I think this is a *major* undertaking to localise. I've set this as something for cr1/GA but it might not be doable. But let us hear what Slava thinks, maybe there is a way ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plu... ] Sean Flanigan commented on JBIDE-2969: -------------------------------------- 10,000, that's quite a few. What if we were to group them by plugin and eliminate duplicates? Would that bring the number down much, do you think? Or are you actually talking about 10,000 unique English strings? (Optimistically assuming it's not really that many...) Would you be able to create an XPath that would reliably pick up the English strings from the .meta files? If so, I could create an Ant task, say XPath2PotTask <https://fedorahosted.org/tennera/ticket/1>;, which would extract the keys and make them available to the localisation team as POT files. (After translation, they would be converted to .properties for use at runtime.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plu... ] Max Rydahl Andersen commented on JBIDE-2969: -------------------------------------------- sean, just to be clear the i18n changes can't make it in before beta freeze; they will/shall be made on the trunk preparing for cr1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plu... ] Sean Flanigan commented on JBIDE-2969: -------------------------------------- Max, I wasn't assuming anything about when i18n might get into the source! Although I see now that this issue has targeted Fix Versions, which should have been a clue for me... Viacheslav, thanks for the reply. Viacheslav Kabanovich (JIRA) wrote: I don't quite follow you, Viacheslav. When you say 851 attribute names, are these the names of seam/hibernate/etc XML attributes which are generated by JBoss Tools? Perhaps we should leave them entirely alone, like the list values you mention further down? But I'll assume not, for now. To get the 4400 attribute names, are you assuming that all "class" strings have the same meaning within all the .meta files in a plugin? Or are you treating every single occurrence separately? Ideally, we need to find the highest level of granularity such that all identical strings (eg "class") have the same meaning. At the lowest level of granularity, every occurrence of every string is treated separately, but you have so many msgids (keys) that the L10n team's job is too big. At the highest level of granularity, identical strings are assumed to have the same meaning across all .meta files in JBoss Tools, but translation becomes nearly impossible because the same string has different meanings in different places. I suspect that the sweet spot is at the level of plugins. All identical strings within a given plugin's .meta files are assumed to have the same meaning. (In practical terms, each plugin would produce one POT file for translation, and each unique string would become a translation key (msgid).) Is that what you were suggesting? I'm not sure about this. I'm not it would be very intuitive to offer keyboard shortcuts that don't correspond to what's visible in the GUI, only to the invisible English translation. I suspect most users would prefer to be able to type part of the string they see. Perhaps we need to support both types of user, with a configuration option to select which they want. Good point. Distinguishing between 'stateless' and 'STATELESS' is already difficult enough in English! If the list is there to select an exact value which is destined for an XML file, we should make that value available to the user. Perhaps in brackets after the best-effort translation? (Eg ステートレス (stateless) and ステートレス (STATELESS). Some users might feel differently though. Sometimes you use a UI because you don't know the syntax of the underlying file. At some point, we might want to allow users to see their own language for simple things like boolean values. I think that can wait until a later release though. Makes sense to me. At least for this release. I gather this relates to the "nye..." versus "fal..." problem. In other words, the new editor would let the user type "fal" (from the model) to select the "nyet" option (as displayed in the UI). As I said above, I'm not sure most users would want that. But there are various ways of implementing it. Whatever makes most sense. Okay, but I think we could use the existing displayName as a lookup key if we want to. Again, whatever makes most sense is fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBIDE-2969?page=com.atlassian.jira.plu... ] Viacheslav Kabanovich commented on JBIDE-2969: ---------------------------------------------- For example, keys for Visual/Source, Source, Preview constants are in org.jboss.tool.common.model/resource/help/keys-model-lists.properties: Model.lists.Visual_Source=Visual/Source Model.lists.Source=Source Model.lists.Preview=Preview -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira