On Tue, 2010-11-02 at 10:34 -0400, Kohei Yoshida wrote: > On Tue, 2010-11-02 at 09:45 +0000, Caolán McNamara wrote: > > On Mon, 2010-11-01 at 22:27 -0400, Kohei Yoshida wrote: > > > Hello Joost, > > > > > > Thanks for the patch. Just pushed to the master branch. :-) > > > > Nothing to do with the patch, but I see a ConvertCountryCode which, > > depending on what it does, might be a candidate to be moved into > > i18npool/source/isolang beside the rest of the code that handles > > conversion to/from iso language names. > > That function appears to return a numerical value representing a country > code from the country code string, and the values appear to be specific > to the VBA layer. So, from what I can see we can't move this into > i18npool/source/isolang since the value set likely differ from the one > that we use internally. However, it *may* make sense to move it to > somewhere common among all VBA implementations (Calc and Writer) if the > country code set is identical between Writer's and Calc's > implementations. The api that uses this ( Application.International ) certainly does exist in at least the word and excel api, however it's not clear if the country codes are indeed the same. I didn't contribute this particular api and looking at the info ( various documentation & metadata ) I don't even see where those country codes are defined for excel ( there is a WdCountry set of constants for word that looks promising but has different numbers from those returned for various languages in the method mentioned. So.. I'd leave it until someone actually figures out what numbers are used for what country/language in each application api before trying to amalgamate the implementation
Noel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
