Unlike JSON files, order matters in XML files. For example, imagine this:

<h1>This is a section</h1>
<p>Some content.</p>

<h1>Here's another section</h1>
<p>More content.</p>
<code>Some sample code.</code>


If you order them, then you get:

<code>Some sample code.</code>
<h1>This is a section</h1>
<h1>Here's another section</h1>
<p>Some content.</p>
<p>More content.</p>


That doesn't make any sense.
We also shouldn't order attributes. There may be a reason the author has put them that way.
When working with XML, it's good to show the XML in a form that makes it easier to read the document, in a tree form, but we don't want to otherwise alter that content.

These blank lines should remain. Check our style guide on Notion for where blank lines should go.

Can you add a comment about why the score is 1 here, based on what we've diagnosed?

os is a Python Standard Library module, so it should go in an import group after __future__ but before django. See the style guideline on Notion for import groups.

"XMLReviewUITests"

No blank line between class and the docstring.
We also tend to include the full module path in the docstring for unit tests, so the full one for XMLReviewUI.
The blank line should go after.

Helper functions in unit tests should be private (prefix with a _) and put at the end of the class.

Typo, and this doesn't follow our documentation guidelines.

Ideally, we wouldn't include data files, since that makes it harder to have self-contained tests and to provide variations on the tests. It's not even needed in this case, since SimpleUploadedFile takes the data directly. This function should take the data, and that should be provided in calls to the method instead of opening a file.

Each component of os.path.join should be a single path entry. No . or /. file_diretory must also be its own parameter -- no concatenation, since that's the point of os.path.join.

Blank line between these.

You want as little as possible in this with block. Confine it to the SimpleUploadedFile creation.

Docstrings should be in the form of:

"""Testing <class>.<method> <condition>"""


Like:

"""Testing XMLReviewUI.get_rendered_lines orders tag results"""


Same in other tests.

This is all part of the Python Standard Library, so it should be in the same import group.

Alphabetical order. This would be:

from django.utils import six
from django.utils.six.moves import ...
from django.utils.translation import ...

This is part of the Python Standard Library, and should go in the appropriate import group.

Lines are wrapping way too soon.

This must describe the results of the method (a Yields section). See Notion for info on writing docs.

Blank line between these.

We don't use the inline if .. else .. form. This should be expanded into a standard if/else.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Blank line here.

Docstrings must have a single-line summary. IT cnanot wrap.
Others are wrapping too soon.

This is going to show up wrong in the docs. If you want to show inline code, use double backticks around it.
This format being shown here, though, is a bit confusing, and seems more like an implementation detail. It's better to describe this and then provide an example of a value separately.

This will need a docstring in our standard format.
So will other methods in this class.

Double prefixes should never be used in Python, except for operators (like __eq__) or other special methods (__str__, __repr__).
Private methods should also go after all public methods.

This needs a docstring.
It's also in the wrong casing format. find_attributes would be more correct.

Blank line here.

These can be combined into one conditional.

Blank line here.

This also needs a docstring and should be add_indent.

I think some of your variable names (like t, dc and dc) could be more descriptive. For example, I'm assuming dc means "dictionary children", but it's not immediately obvious.

Similar comment to above. The variable o could have a more descriptive name.

I don't have to much insight on what you are working on but I feel that there are a few things you can do to make this part of the code more maintainable and readable for others.

All your testing happens in the get xml file function, but base on the nasme, that should be returning an xml file of sorts, not testing for nested XML.

You don't verify if any exceptions are thrown here. Rather than waiting for a KeyError or TypeError when in etree_to_dict, you should get an IOError and handle that.

Is this too broad for the types of exceptions beeing handled?

flow is really odd and there are no comments to explain what is happening in each block.
You could use intermediate functions to make it obvious too.

This docstring should explain the inputs expected and return values.
You also need to say what type is expected for t because it makes the rest of this code a little unclear as we don't know what attributes are guaranteed to exist.

Add a comment for why len(value) ==1: is important.

Why is it value[0]? Add comments to explain.

Is it possible for strip() to return none?

Why are you creating a new dict and adding t.tag to it? Is there any benefit over adding text to t.tag?

It isn't obvious that this will only be run if t.attrib and t.children are None

confusing operation. You are reassigning an input to the return value of a function to which its intial input was the value you are reassigning. 
Maybe use an intermediate?

You have attrib and attrib_in, both of these side by side are a little confusing. Better names are required.

You should add a comment to explain what is happening here.

Along with providing a better name for the variable, you should add what args and kwargs are representing in your docstring.

Considering this is an IO Stream, is there possibility of not having a value by the end or have a possible IO error?

You'll need to document the expected results and inputs.

More index operations that aren't clear why.
Docstrings could give insight on this.

Should say 

Add indention on new line with an indent of the current depth plus one.

You should explain why key[1] is important here.

what if the wrong type is passed in?

I understand the _ is for localization? How exactly does that lookup work?

Perhaps consider using enums for this and text

Not sure this is needed. Why not call self._fixname directly?

It may be more clear if you put key[0] == "text" (or better yet use an enum) and add this as an and clause to the if above it to reduce nesting

%s may round things (is this what you want?). Consider using %r if you don't want rounding. Have a look at this blog post for some more info.