Is it okay, if you give HTML fragments to translators? If not, what do you give them and how do you get the HTML fragments back?
So is this okay to hand down?
Hey <i>Bob</i>, what's your <span class="important">name</span>?
Is it okay, if you give HTML fragments to translators? If not, what do you give them and how do you get the HTML fragments back?
So is this okay to hand down?
Hey <i>Bob</i>, what's your <span class="important">name</span>?
You give the translators whatever you agree with them (i.e. ask the translators what they need, not other programmers).
Throwing the markup away and giving them word fragments without context is likely to cause translation errors though. Context is important for meaning.
To elaborate on my comment on Quentin's answer:
We're using Ruby on Rails for our UI, but we ship an appliance. There's no URL we can send our translators for context. We'd have to send them an entire ISO, and even then they wouldn't be able to actually use the application without proper data.
Instead, we send them the raw Yaml files from config/locales
, where there's one resource file per target language: en-US.yml, fr.yml, de.yml, etc. They import these files into whatever system they use, translate, export, and send us the translated Yaml. If they need context, we send them screen shots.
So anything that Rails accepts as a translatable string, we send it directly to our translators. We even extended Rails's capabilities to accept ERb templates within strings. That was a very bad idea :-)
I'm not saying this is the best solution. We often get back invalid Yaml, or they miss strings or don't translate as accurately as they could with perfect context. But it works in general.
If you're using some software to generate the html (ie - php/asp/asp/net/etc) then don't give the translators the resultant html, give them the resource file you used to generate the html.
You will then have a resource file for each language you want to support. You can then use either browser language settings (accessible via headers server side), the request url or even a cookie (after you asked them what language they prefer - see quietpc.com for an example of that) to figure out which language the user wants to see you site in.
Now you know what language to present your site it, you can then write you server side code to read the relevant resource file and you're all set!
So, instead of this ...
Hey <i>Bob</i>, what's your <span class="important">name</span>?
... you would have this ...
<%=Resources.Hey%> <i><%=Name%>, <%=Resources.Whatsyour%> <span class="important"><%=Resources.Name%></span>
But, splitting things up like this is very bad IMO. It is better to reword things so they're not split up. I don't think this is a great example as you're asking Bob what his name is. It's Bob!!
I always try to lay out my pages so that I don't intermix variables with text.
Example ...
Name: Bob
Mood: Happy
Name and Mood can be translated. Bob and Happy are coming from variable somewhere, ie - they're dynamic.
Example markup ...
<table>
<tr>
<td><%=Resources.Name%></td>
<td><%=Name%></td>
</tr>
<tr>
<td><%=Resources.Mood%></td>
<td><%=Mood%></td>
</tr>
</table>
This is just how I've approached it in the past as I don't speak any other languages other than (bad) english, I don't really know if the way sentences are structured changes based on context. So, I've always tried to avoid sentences with embedded variables in them.