[ckan-dev] Notes about the translation process

[Toby Dacre]

On 16 April 2013 21:02, Stefan Wehrmeyer <stefan.wehrmeyer at okfn.org> wrote:

> Dear CKAN-Devs,
>
> I just translated some CKAN copy to German and stumbled upon a couple of
> things. Quite clearly there is a section missing in the contributing
> section of the docs about how to treat copy (at least I couldn't find any
> info about it).
>
>
Stefan,

Thanks for this. I agree that we need to do some work around this to make
the translators life easier.  At some point we will remove the old genshi
templates that create some noise.  We should also be more consistent in our
use of substitutions at the moment we have

a) ... %s ...
b) ....%(..)s...
c) ....{...}...

we should look at simplifying the number of ways we do the same thing and
...{descriptive_name}.. sounds the best

I think I might look at some tests to automate some of the rules but others
are subjective.  I happened to look at the translation string yesterday and
there are some very untranslatable looking ones.

This advice is really useful

@sean/@johnmartin can you look at getting this into our developer docs


> Feel free to add to the following:
>
> - Leave out unnecessary HTML from translation strings as best as you can
> (e.g. surrounding p-tags).
> - But don't split a sentence up in little translatable string pieces!
> Rather include some HTML (e.g. a-tag). Context is king.
> - If a string contains a variable amount, set up translation for singular
> and plurals.
> - If a string is ambiguous, add translation context (Jinja might not
> support this feature). E.g. "filter results", is filter a verb or a noun?
> (see: https://www.gnu.org/software/gettext/manual/html_node/Contexts.html)
> - If a string contains substitutions, name them descriptively.
> {dataset_title} beats {dataset} and especially {0} anytime.
> - Put punctuation inside the translatable string, leave unnecessary
> whitespace out.
> - Don't make translators translate stuff, that doesn't need translation
> (legacy_templates?).
> - Define which second-person pronoun should be used for translations:
> T-form or V-form (see https://en.wikipedia.org/wiki/T–V_distinction ).
> Settle for one or set up a two translations for one language.
> - Put up a wiki page that defines the canonical translation for specific
> CKAN terms in the different languages (e.g. "related item")
> - Localise dates, times, currency formatting, if possible.
>
> For writing copy:
> - Review copy like you review code: There is one CKAN design, there should
> be one voice. Many developers have many voices (technical error message
> voice vs. friendly explanation voice). Apart from copy schizophrenia: many
> voices also make translation harder.
> - Use punctuation.
>
> Please contribute, put it somewhere permanent and make developers read it.
>
> Cheers
> Stefan
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130417/35c2783d/attachment-0001.html>