Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Implement an option in *.ipt file (Vault project) to enforce/lock Content-Center Language for Vault project.
The goal is to avoid multi-language CC parts like that:
This situation can occurred when you work in a multinational team where folks use Inventor with localized GUI:
Content-Center is automatically switched to the same language and/or can be too easly changed.
Consequently, issues can occur, for example when BOM is set up: parts descriptions i several languages.
PS: this feature could also be implemented in Vault option in the same way as *.ipj file can be locked. despite, it sounds me more pertinent to host this in *.ipj itself.
If you are working with vault you can simply lock the content center folder in vault so that nobody can create new language-specific folder into it, so if user create a standard part in wrong language, he cannot check in. Of course, this is not the case if you are using vault basic.
I completely agree with pierre.masson Please note that not all you customer have or want to work with VAULT. Let me have the possibility to "grey out" the Tools / Language setting as a registry option, So every Content-Center elements will be managed in the same directory.
Actually it is impossible to manage the content center element if the user can create for each language an instance of the same washer.
repeat it for each language you need and it's game over
P.S.: the guy who did it has left Autodesk, now Autodesk doesn't know why he did it. Till Adsk doesn't come out with a formal solution, this trick will fix your problem
This would be a very valuable addition - when working in a Global team with users on different language apps. I hope it makes it to the next relase, and have also put my vote om similar request in the Vault Ideas Forum Regards
I completely agree that there is a problem. We use Vault in international replication and the problem is obvious. However, I would be curious to see the solution because I think it is the management of languages in the Content Center as a whole that should be reviewed. For example, I don't understand how a family can have a different name between two languages.
Hello @freesbee, I've got the same issue. We got an international team and I would like to lock the language of the content center to english. I don't understand your instructions though (quoted below). Could you please explain in further detail? Thanks.
"...
anyway:
mklink /J de-DE en-US
repeat it for each language you need and it's game over
Inventor creates by default the IPT for each specific content center member in the language location currently active. If the member is already found to be there, it does NOT create a new one, but it uses the one available instead. If you use Autodesk standard content center files, you will get also some iProperties in that specific localization, as the description for instance. This may be good or not, depending on Your specific implementation. For my implementations it is NOT recommended, as we have 8 different languages as custom iProperties in our ContentCenter and we do NOT need to generate additional IPT files for handling this. Of course we can also integrate additional languages anytime without increasing the number of files, which is also a valuable asset.
If you use your custom libraries (always the best strategy) then you have more flexibility over this aspect, but in general you do NOT want to generate 10 different IPTs which are identical (besides some localized iProperty), just because the user was funny and has been playing around with content center language (or because you have users on different localization).
Now let's say that one language folder is completely populated because all members have already been generated: "en-US" for example. If you create one symlink per each language with that command ("directory junction" in Microsoft terminology), then inventor will be convinced that you already have the member generated per each language, while accessing always the same file, and will NOT generate a new file on each language.
In the specific example up here, if the user switches his language to German because he is not able to locate a set socket screw on the English GUI and then picks the member, then Inventor will simply reuse the member that was generated in English, keeping everything clean and consistent.
Of course being able to lock the ContentCenter language as the idea suggests would be an ultimate solution, as also the much wider one exposed here:
Honestly I do not care very much of the "family name": in my implementations families are identified by the Norm that they follow, so they will be something like "ISO 4032". The description can be localized, but again... most users do not even know how to expose the description in the content center view: they just go there, pick the part that they need and keep on working. After a few days they will learn the ISO numbers, and they will be absolutely fine with that. When searching for categories, Autodesk categories are already properly localized and will match the active ContentCenter language.
If you want to control language specific family names, just switch to the language you need, and rename the family (absolutely undesirable for me: I would get lost myself in my own creation 😂).
The interesting part is "how to have localized iProperties so that you can switch you partlist seamlessly in different languages" keeping everything consistent. This allows you even to perform automatic translation of drawings, assuming that also all other elements are already in place.
There are a few strategies that could be used to achieve this, and it is only possible with custom authored families. In my case I have created a bunch of custom iProperties in the family template, each one of them pointing to one specific language. I pick the right property in the partlist, and the game is done.
So my ISO 4032 family template has the following custom iProperties: desc_en = hexagon regular nut
desc_de: Sechskantmutter
desc_fr: écrou hexagonal
desc_es: tuerca hexagonal
desc_it: dado esagonale
desc_pt: porca sextavada
desc_ru: гайка шестигранная нормальная
desc_zh: 六角螺母
and I can scale anytime adding additional languages, even those not considered by the 13 native Autodesk localizations, even if I never got even close to a company needing this level of customization.
Nevertheless this flexibility and leanness is the real benefit for our systems.
...well, if I understood it correctly "FUTURE CONSIDERATION" means that they accepted the point. A solution is still not scheduled to be offered, but the first suitable developer slot to address that point will be taken to address it...
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")