Re: Data localization
- In my opinion, the main problem is that data can not be localized for
now. So internationalisation should be done and is a priority. Providing
localizations is a second step, and it would take time; but it cannot be
done, even by users, so the internationalization is the main problem.
I’ve updated the wiki with more details on many things, also tried to
separate internationalization problems and localization ones.
Le mardi 13 décembre 2011 à 15:23 +0000, thpr - thpr@... a écrit :
> --- In firstname.lastname@example.org, "masaru20100" <hooya.masaru20100@...> wrote:I pointed the problem because it is UI strings that are dataset
> > In the process of updating the translation, I found another potential problem: depending on the system, some element is not translated the same way. This particular case is rank that is not translated the same way in D&D 3.x and Pathfinder.
> > Doing system dependant translation might complicate things quite a bit.
> This depends on what is being translated. If it's data items, then the system I proposed will handle that. If it's NOT (meaning it's things in the UI) then we will have to address that in a more complicated fashion.
dependent. In this case, both are probably understandable but having the
good term used would be better.
Compared to data set internationalization, this is not that important,
but if, somehow, the solution could handle that aspect, it would be
> > The reason I mention those formats, is that they are tools (meant for translators) that manage either format and ease translating work. When using another format, those tools become useless.If there is no list of strings to translate for the default language, a
> We can evaluate whether we can get them to work without ambiguity. Also note that we would build the strings dynamically inside the code and there would be no list for the default language (English in most cases), so anything expecting a list of items from the default language (as a method of telling what is/is not completed) for the translator would not work. (Part of the investigation here should be how much of this would actually be usable by the translator given how we would be doing the work in the code)
tool to generate that list would be a must have to start doing
translation in a language.
A tool that produce and update a standard format would be a nice
Is there an issue in JIRA about data localization. I had created a wiki page (http://wiki.pcgen.org/Internationalization) with plenty of text on the matter (including the mails in this topic), but I have no idea if it's advancing or not.
- Yes, James has fixed a number of CODE Jiras recently - take a look at the
recently closed issues in that project. -K
On 3 September 2012 06:35, masaru20100 <hooya.masaru20100@...>wrote:
> Is there an issue in JIRA about data localization. I had created a wiki
> page (http://wiki.pcgen.org/Internationalization) with plenty of text on
> the matter (including the mails in this topic), but I have no idea if it's
> advancing or not.
[Non-text portions of this message have been removed]
Those CODE jiras were concerned with UI localisation. We aren't tracking
data localisation in JIRA yet. That project will have to wait for after
the 6.0 release.
On 3/09/2012 6:20 PM Martijn Verburg wrote
> Yes, James has fixed a number of CODE Jiras recently - take a look at the
> recently closed issues in that project. -K
> On 3 September 2012 06:35, masaru20100<hooya.masaru20100@...>wrote:
>> Is there an issue in JIRA about data localization. I had created a wiki
>> page (http://wiki.pcgen.org/Internationalization) with plenty of text on
>> the matter (including the mails in this topic), but I have no idea if it's
>> advancing or not.