-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XLIFF: expose unit IDs and groups in UI #752
Comments
Is this accurate, i.e. there's no additional metadata? Would you be able to share (privately, [email protected]) real-life file for better testing? You're correct in your observations as well as in this:
This is indeed the plan, together with exposing the symbolic IDs in the UI as actual IDs. As you can probably tell, there are UI artifacts from Poedit being originally for PO files only. Doing that is a bit more work than I won't be able to fit into 3.1, but showing the symbol ID in the Notes for translators sidebar is simple enough to make it, with further improvements following. |
Handle 'resname' (XLIFF 1.2) and 'name' (XLIFF 2) attributes of translation units and show them, if present, instead of the 'id' attribute as the item's ID. These are meant to be used for symbolic, human-readable identifiers, so are the appropriate thing to expose. See #752.
Thanks for the response! Yeah it seems like there's a Which might not be ideal if the UI did expose it as an expandable tree cause you'd have a redundant group node under each file node unless POEdit did some kind of smart "flattening"? Here's a trimmed down XLF with just that single string in it if it's useful for testing? (had to zip it for GitHub to let me upload it) Or if you need more strings let me know and we can maybe email it privately. Or feel free to generate your own string tables via the Unity localization package if wanting to sift through the details of their output format. It turns out CrowdIn also don't show the |
It's always useful to have "real-life" files / sets of files to have a better understanding e.g. which parts of spec are actually used (full XLIFF 2.x is enormous spec and approximately nobody uses all of it…).
This was poor handling on Poedit's end, Unity is doing the Right Thing ™ here. Quoting the spec on the meaning of the optional
…and so in 3.1, after 4c4fef3, Poedit will prefer to use |
Hi there,
We've been using XLIFF 2.0 for our translation exchange format, and our game engine (Unity) spits out an eg.
GameTables_de.xlf
file that look likeThe game engine's localization system assigns a unique number (guid) for each string, which it then puts into the
id
attribute of theunit
, but then includes the user-facing "key" we enter as thename
attribute. Each string table in the game is given its owngroup
element, with the table title in thename
attribute. The above is an entry with key "Leaderboard_RetryRequestButton" from our "UI" table.As far as I can tell there isn't a way to add additional columns to POEdit to display the
name
orid
attribute?I found a checkbox to show the "id", but it seems to just print out more of an "index within the POEdit list".
It does seem to show the
unit
'sid
attribute in the details panel when you have a row focused, along with the comment:But it'd be give translators much more context to also be able to see the key we entered.
Ideally POEdit could also have an option to group things in the list, almost like a tree-view where you can expand/contract groups. Since we might have a table (that's exported as a
<group>
element) for general UI, one for Credits, one for Dialogue, one for GameModes, one for OptionsMenu etc. and leave the group name out of the individual string keys. So exposing the group to the translators (even if just as another column instead of hierarchically) would probably also make their lives easier.Thanks!
The text was updated successfully, but these errors were encountered: