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

Multi-Language Add-In for Visual Studio


"Remove" Lang From Supported Languages ?

We have send out translations to several translators now.
We did get a lot back well translated - but some was created in out system, but didn't come back in time..

How do we limit the list of "Supported Languages" without manually maintaining it? Is it possible to mark a language as "In Progress" (or remove "Is Supported" flag)?

I really like the Supported Language approach you got - but I can't find where to mark a language as not supported while working on it (and it takes ½ hour to remove and add a language, so I would appriciate being able to keep the data in there - but just holding back the option to select the language in the UI).

By Nick Niebling How do we limit the list of "Supported Languages" without manually maintaining it?


Okay I just read that again, and that wasn't so clear..

Of course I need to manually maintain it somewhere :-) but I would like to do it from a central point in your software :-) I use the "Supported Languages" list (you provide in the ML class) several places (I thought I would get all languages back). Hope that was more clear?


A colleague just pointed out that we could just insert a string called "Supported" - if it's translated "empty", we should remove from our "supported list"..

Even though this solution would work kind of "generic", I would still have to implement it everywhere you can select language (profile edit and create new profile in different contexts etc.).

Hope you got a better solution for me :-)

Germany

Hi Nick,

I could add this feature for you.

There is a languages table in the project database. I could add an enabled column to this table, and only include languages in the SupportedCultures array if they are enabled. I could add a form to enable or disable languages, or alternatively add checkboxes to the column headers. It wouldn't really be a lot of work.

However, I an inclined not to do it, because I feels like featureitis. I think I would prefer it if you implement your own system.

The simplest method would be to remove the disabled languages from the SupportedCultures array. However, this array will be regenerated if you add a new language, overwriting your changes.

Alternatively, you could add a copy of this array, e.g. SupportedCultures2, which you maintained by hand. Another way would be to add a second array, listing only the languages which are not supported, with some program logic to exclude these languages. Or of course, the method suggested by your colleague.

If you think it is a really useful feature, which other users will require, then you can still try to convince me to implement it.smile

Phil


You have some excellent implementation suggestions rolleyes And you are quite right - this is a very small feature and would be very easy to implement rolleyes So I fully understand why you won't do it.

Why is this feature needed?

However, I wouldn't call it featureitis, as this would refer to a feature not aiding the original goals of the product. I believe a localization tool as yours, should have a goal to make it as easy as possible to both initialize and maintain translations. And if this is the goals, the reality is that you in most cases won't get back all languages from the different translators at the same time - but you might want to publish the code for some reason anyway.

We did sent our texts out to around 10 translators - and we only got 3 back within the deadline. So we could postpone our release date, blaming our translators for not delivering - or we could release the 3 new languages we did get back alongside with the new features and bug-fixes we have promised our customers.

So we have to choose whether we want to be the good guys and deliver our part on time or if we want to blame our translators and hope our customers doesn't get angry with us... What whould you do? rolleyes (the last thing isn't really an option).

And as you might recall, it takes very long time for us to get translations from Google when we add new languages to our project (and often the tool is crashing while processing cry ), so even though deleting the untranslated languages seems like another good approach, adding the languages again is such a waste a time that this isn't an option as well.

What I did..

But I do agree with you - this is very simple.. I just have to store a string[] SupportedCultures with global availability somewhere myself - and so I did biggrin So I did fix it - I actually just wanted to help you improve your product for others in the future as I really believe this is a feature that would simplify the process.

It's also a matter of "Separation Of Concerns" - All the code concerning localization logic is placed in your tool - except for "supported languages" which I have to place global "somewhere else" now. So updating your tool could en theory affect my implementation of this supported cultures list. i beleive I've made a generic fix, but what if you decide to change format (to gain performance or for any other reason) - that would break my fix :-)


No matter what smile

Thank you for this great tool .. i enjoy working with it (in the big picture rolleyes)

Best regards,
Nick Niebling


Hi there
just find this old thread but for me it is not totaly clear how i can remove a language.
I have four languages and want to remove one ogf them.
What is the easiest way?

Best Alex

> Hi there
> just find this old thread but for me it is not totaly clear how i can remove a language.
> I have four languages and want to remove one ogf them.
> What is the easiest way?
>
> Best Alex

ok, found it
right click in the language column and then "remove language"